6:26 a.m.
Hello folks!
Debian users have tried out installing more recent SyncEvolution
packages and ran into issues that apply to all distros shipping
SyncEvolution. I'd like to raise awareness of these issues and discuss
how to solve them.
SyncEvolution depends on features in recent libsynthesis, for example
additional XML tags. Running SyncEvolution with an old libsynthesis will
trigger XML parser errors.
First problem: because the ABI of libsynthesis has not changed, the
soname of libsynthesis has not been changed either. If I had, older code
using libsynthesis would have unnecessarily been prevented from using
the more recent libsynthesis. To solve this, add versioned dependencies
to your SyncEvolution packages. To be on the safe side, please assume
that SyncEvolution always depends on the version of libsynthesis that it
is bundled with.
Second problem: syncevo-dbus-server might be running while packages are
updated, which leads to the situation that it uses an old libsynthesis
in memory.
I'm not entirely sure how to solve that second problem. I could try
dynamic loading of libsynthesis, but that only covers the libsynthesis
dependency and not the update of SyncEvolution itself, nor of any of the
other shared libraries in use by the process. If anyone has suggestions
for how user-space restarts are meant to be handled by distros, then
please let me know.
--
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.
Hi!
Am Dienstag, den 15.03.2011, 11:26 +0100 schrieb Patrick Ohly:
Second problem: syncevo-dbus-server might be running while packages
are
updated, which leads to the situation that it uses an old libsynthesis
in memory.
I'm not entirely sure how to solve that second problem. I could try
dynamic loading of libsynthesis, but that only covers the libsynthesis
dependency and not the update of SyncEvolution itself, nor of any of the
other shared libraries in use by the process. If anyone has suggestions
for how user-space restarts are meant to be handled by distros, then
please let me know.
I’m surely no expert on this matter, but I know that Ubuntu has somewhat
a mechanism for this, since firefox upgrades notify the user to restart
firefox.
The postinst script for firefox contains this snippet:
if [ -d $UPDATENOTIFIERDIR ] ; then
# pgrep matches application names from /proc/<pid>/status which is
# truncated according to sys/procfs.h definition. Problem is it's
# platform dependent. Either 15 or 16 chars.
if [ `/usr/bin/pgrep -x -c firefox` -ne 0 ] ||
[ `/usr/bin/pgrep -x -c $APPNAME` -ne 0 ] ; then
cp -f $LIBDIR/$APPNAME-restart-required.update-notifier \
$UPDATENOTIFIERDIR/$APPNAME-restart-required
else
rm -f $UPDATENOTIFIERDIR/$APPNAME-restart-required
fi
fi
/usr/lib/firefox-3.6.15/firefox-restart-required.update-notifier
contains:
Name: Firefox restart required
Name-fr: Relancement de Firefox 3.6 requis
Priority: High
Terminal: False
DontShowAfterReboot: True
DisplayIf: pgrep -x firefox -U $(id -u) > /dev/null
Description: Firefox has been upgraded (or reinstalled) and must be
restarted.
Please quit and restart your web browser now.
Description-fr: Firefox a été mis à jour (ou réinstallé) et doit être
relancé.
Veuillez quitter et redémarrer for navigateur.
The downside of this is that it requires manual user intervention, but I
don’t know if there is an easy way for end-users to restart
snyncevo-dbus-server. An alternative could be to use the generic
“restart required” mechanism in update-notifier (didn’t investigate the
details further, but should be manageable to find out).
syncevo-dbus-server would still have to handle issues caused by
mismatching versions, but it could simply cancel operations when it
detects such a situation, since the user knows that he or she cannot
expect things to work properly until the system is restarted.
Just what came to my mind spontaneously, there might be better
solutions.
Regards,
Frederik
8:27 a.m.
On Di, 2011-03-15 at 11:19 +0000, Frederik Elwert wrote:
Hi!
Am Dienstag, den 15.03.2011, 11:26 +0100 schrieb Patrick Ohly:
> Second problem: syncevo-dbus-server might be running while packages are
> updated, which leads to the situation that it uses an old libsynthesis
> in memory.
>
> I'm not entirely sure how to solve that second problem. I could try
> dynamic loading of libsynthesis, but that only covers the libsynthesis
> dependency and not the update of SyncEvolution itself, nor of any of the
> other shared libraries in use by the process. If anyone has suggestions
> for how user-space restarts are meant to be handled by distros, then
> please let me know.
I’m surely no expert on this matter, but I know that Ubuntu has somewhat
a mechanism for this, since firefox upgrades notify the user to restart
firefox.
The postinst script for firefox contains this snippet:
if [ -d $UPDATENOTIFIERDIR ] ; then
# pgrep matches application names from /proc/<pid>/status which is
# truncated according to sys/procfs.h definition. Problem is it's
# platform dependent. Either 15 or 16 chars.
if [ `/usr/bin/pgrep -x -c firefox` -ne 0 ] ||
[ `/usr/bin/pgrep -x -c $APPNAME` -ne 0 ] ; then
cp -f $LIBDIR/$APPNAME-restart-required.update-notifier \
$UPDATENOTIFIERDIR/$APPNAME-restart-required
else
rm -f $UPDATENOTIFIERDIR/$APPNAME-restart-required
fi
fi
/usr/lib/firefox-3.6.15/firefox-restart-required.update-notifier
contains:
I don't seem to have that on Debian.
The downside of this is that it requires manual user intervention,
but I
don’t know if there is an easy way for end-users to restart
snyncevo-dbus-server.
No, which makes this notification-based method unsuitable for the
daemon.
The problem is that the package update must interact with one or more
user sessions. Sending a D-Bus message to the syncevo-dbus-server on the
session bus is non-trivial. The system bus could be used, but only for
broadcast signals.
My current thinking is to solve the problem in syncevo-dbus-server
locally, without support by the package manager:
* at startup, determine a list of all shared libraries loaded into
memory (/proc/self/maps)
* set up change notifications for these files
* when triggered *and* idle, restart the daemon
If the package update happens while a sync starts, then there is a risk
that it'll fail, but I expect that time range to be very small.
--
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.
10:57 a.m.
On Tue, 15 Mar 2011 13:27:03 +0100, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
My current thinking is to solve the problem in syncevo-dbus-server
locally, without support by the package manager:
* at startup, determine a list of all shared libraries loaded into
memory (/proc/self/maps)
* set up change notifications for these files
* when triggered *and* idle, restart the daemon
I'm certainly in favour of having things done without the package
manager ;). Did you consider some kind of check done by the client
(e.g. syncevolution cli tool) saying hey dbus server, I am version X,
are you new enough? If the answer is no, trigger a restart. Or perhaps
versioning the dbus service names as was already suggested. I might be a
bit messy if you really need to change it with every syncevolution
release.
d
11:01 a.m.
On Fr, 2011-03-18 at 14:57 +0000, David Bremner wrote:
On Tue, 15 Mar 2011 13:27:03 +0100, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> My current thinking is to solve the problem in syncevo-dbus-server
> locally, without support by the package manager:
> * at startup, determine a list of all shared libraries loaded into
> memory (/proc/self/maps)
> * set up change notifications for these files
> * when triggered *and* idle, restart the daemon
I'm certainly in favour of having things done without the package
manager ;). Did you consider some kind of check done by the client
(e.g. syncevolution cli tool) saying hey dbus server, I am version X,
are you new enough?
That won't solve the problem when syncevo-dbus-server is running
permanently to execute regular time-based syncs. In that case files will
be updated underneath the daemon, causing it to fail in syncs, without
the command line or GTK UI talking to it at all.
--
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.
9:56 a.m.
On Fr, 2011-03-18 at 15:01 +0000, Patrick Ohly wrote:
On Fr, 2011-03-18 at 14:57 +0000, David Bremner wrote:
> On Tue, 15 Mar 2011 13:27:03 +0100, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
>
> > My current thinking is to solve the problem in syncevo-dbus-server
> > locally, without support by the package manager:
> > * at startup, determine a list of all shared libraries loaded into
> > memory (/proc/self/maps)
> > * set up change notifications for these files
> > * when triggered *and* idle, restart the daemon
>
> I'm certainly in favour of having things done without the package
> manager ;). Did you consider some kind of check done by the client
> (e.g. syncevolution cli tool) saying hey dbus server, I am version X,
> are you new enough?
That won't solve the problem when syncevo-dbus-server is running
permanently to execute regular time-based syncs. In that case files will
be updated underneath the daemon, causing it to fail in syncs, without
the command line or GTK UI talking to it at all.
I've implemented the shutdown/restart feature in the syncevo-dbus-server
itself, as outlined by me above.
I implemented a slight delay of 10 seconds before the the server shuts
down or restarts. Making that delay too small would risk restarting
while package upgrades involving the required files is still in
progress. In the best case, it'll just restart again (likely for long
running system updates?). In the worst case, it will fail to restart
(system inconsistent) which then prevents further automatic syncs.
Making it too large means that the server is blocked for a long time
because new sync sessions are prevented right away.
I hope I have covered all corner cases, like file updates happening
while a sync session is currently active. I also wrote some tests,
including these corner cases.
I'd appreciate if someone could try out this code - David?
For tracking I created a bug entry:
https://bugs.meego.com/show_bug.cgi?id=14955
commit 23464d616a1a6584ea433e64f62b130cfd33205d
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Mar 28 13:52:28 2011 +0200
syncevo-dbus-server: shut down after on-disk changes are observed (BMC #14955)
syncevo-dbus-server must restart after its installation was updated or removed.
Otherwise further sync attempts can fail. This was seen in practice when
SyncEvolution 1.0 was updated to 1.1 (Debian bug #617320): the in-memory daemon
used an old libsynthesis, but the on-disk XML files required more recent
libsynthesis features.
In general, *any* update of something loaded into memory should
trigger a shutdown or restart. A shutdown alone is okay when no
automatic sync scheduling is needed (auto sync off for all
configs). Clients will restart the daemon on demand. A restart is
needed otherwise because without it, automatic syncs would stop to
run.
This patch implements the shutdown part. Restart still needs to be
implemented. A 10 second delay is chosen between "file modified" and
"shut down". This is meant to ensure that a future restart does not
occur too soon (before all file changes are done). It's still a bit
racy, but a better solution would depend integration into
distro-specific hooks ("package update complete"), which is hard or
impossible (installation via "make install" or "tar xf").
This new feature is tested by test-dbus.py, including several corner
cases:
- testShutdown: files modified in regular intervals for a while
- testSession: a running session prevents the shutdown
- testSession2: same as testSession, with different timing
commit ec6eb438b32fdcbca665f4599355eab95d8644f0
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Mar 28 15:43:33 2011 +0200
syncevo-dbus-server: restart when auto sync is enabled (BMC #14955)
This patch also covers the case that the server needs to restart
because it has to run automatic syncs. The restart is implemented as a
brute-force execve() after removing output redirection, using the
original argv and env arrays (Restart class).
--
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.
6:51 p.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
Op dinsdag 15 maart 2011 11:26:38 schreef Patrick Ohly:
Hello folks!
Debian users have tried out installing more recent SyncEvolution
packages and ran into issues that apply to all distros shipping
SyncEvolution. I'd like to raise awareness of these issues and discuss
how to solve them.
Might this also be related to my recent synchronisation problems?
Since your clear reply on January 2nd I set up a syncevolution config to synchronised the
file
/home/hansdej/.SyncEvolution/Calendar/calendar.ics
with my N900 via bluetooth & the SyncML server builtin the N900 (With the capital C in
uri=Calendar)
It worked fine until a few weeks ago, now it seems as if the file-backend does not know
where to look anymore:
(draugen is the name of my N900)
*****************************************************************
hansdej@debian]/home/hansdej>syncevolution draugen calendar
[INFO] addressbook: inactive
[INFO] calendar+todo: inactive
[INFO] memo: inactive
[INFO] todo: inactive
[INFO] Server sending SAN
[ERROR] Error allocating creating calendar
[INFO] calendar: inactive
[ERROR] fatal error (local, status 10500)
Synchronization failed, see
/home/hansdej/.cache/syncevolution/draugen-2011-03-21-23-43/syncevolution-log.html for
details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| fatal error (local, status 10500) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Mon Mar 21 23:43:03 2011, duration 0:04min |
| fatal error (local, status 10500) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: Error allocating creating calendar
[ERROR] command line execution failure
*****************************************************
FYI the calendarfile Header:
BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
etc.)
Am I to look further for some error of my own, what could cause this:
"Error allocating creating calendar"
I also tried setting up the syncevo-http-server on my desktop PC on the same account and
then run syncevolution from a prompt on the N900, this also lead to an error indicating
that the calendar.ics file whas not found or improperly accessed.
Any hints, or should I wait until some general bug is solved?
Thank you.
SyncEvolution depends on features in recent libsynthesis, for example
additional XML tags. Running SyncEvolution with an old libsynthesis will
trigger XML parser errors.
First problem: because the ABI of libsynthesis has not changed, the
soname of libsynthesis has not been changed either. If I had, older code
using libsynthesis would have unnecessarily been prevented from using
the more recent libsynthesis. To solve this, add versioned dependencies
to your SyncEvolution packages. To be on the safe side, please assume
that SyncEvolution always depends on the version of libsynthesis that it
is bundled with.
Second problem: syncevo-dbus-server might be running while packages are
updated, which leads to the situation that it uses an old libsynthesis
in memory.
I'm not entirely sure how to solve that second problem. I could try
dynamic loading of libsynthesis, but that only covers the libsynthesis
dependency and not the update of SyncEvolution itself, nor of any of the
other shared libraries in use by the process. If anyone has suggestions
for how user-space restarts are meant to be handled by distros, then
please let me know.
3:13 a.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems? Evolution 2.32?
On Mo, 2011-03-21 at 22:51 +0000, Hans de Jonge wrote:
Might this also be related to my recent synchronisation problems?
No, I don't think so.
Since your clear reply on January 2nd I set up a syncevolution
config
to synchronised the file
/home/hansdej/.SyncEvolution/Calendar/calendar.ics
with my N900 via bluetooth & the SyncML server builtin the N900 (With
the capital C in uri=Calendar)
Let me guess:
* you are using SyncEvolution < 1.1.99
* you use "type=calendar" and
"evolutionsource=file:///home/hansdej/.SyncEvolution/Calendar/calendar.ics" on
the desktop
* you recently upgraded your desktop from Evolution < 2.32 to 2.32
(for example, in Debian Testing)
Correct?
In this case you access a specific .ics file via the EDS calendar
backend. Evolution 2.32 no longer supports the file:// prefix, and thus
triggers the "Error allocating creating calendar" (a bit oddly phrased
because it is a combination of two strings).
Matthew, is it still possible to specify absolute file locations with
the new local: prefix in Evolution 2.32?
I still need to adapt SyncEvolution to 2.32. Currently it should mostly
work (including the pre-compiled binaries from syncevolution.org),
except for:
* nightly testing: depends on file:// semantic
* users with old uri in their "evolutionsource": need to switch to
the name (if it is unique) or the new uri
* users with absolute file:// path: not sure what the replacement
is
--
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:14 a.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems? Evolution 2.32?
On Tue, 2011-03-22 at 08:13 +0100, Patrick Ohly wrote:
Matthew, is it still possible to specify absolute file locations
with
the new local: prefix in Evolution 2.32?
We do support specifying a custom .ics file for calendars, but currently
this has to be configured through Evolution and the custom file location
is stored in the XML blob in GConf (/apps/evolution/calendars/sources).
There's no way to specify it with the URI alone.
I'll also note that "local:$UID" calendar URIs are *somewhat* flexible
in that the file location is defined as:
$XDG_DATA_HOME/evolution/calendar/$UID
$XDG_DATA_HOME defaults to $HOME/.local/share, but you could override
that in e-calendar-factory's environment. That would, however, store
-all- local calendars at the custom location.
10:08 a.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems? Evolution 2.32?
On Di, 2011-03-22 at 12:14 +0000, Matthew Barnes wrote:
On Tue, 2011-03-22 at 08:13 +0100, Patrick Ohly wrote:
> Matthew, is it still possible to specify absolute file locations with
> the new local: prefix in Evolution 2.32?
We do support specifying a custom .ics file for calendars, but currently
this has to be configured through Evolution and the custom file location
is stored in the XML blob in GConf (/apps/evolution/calendars/sources).
There's no way to specify it with the URI alone.
I suppose I must reread our older mail thread about config changes
coming in 3.0, but let shoot of a quick question anyway: further config
changes are coming in 3.0 that will replace this XML blob, right?
I'll also note that "local:$UID" calendar URIs are
*somewhat* flexible
in that the file location is defined as:
$XDG_DATA_HOME/evolution/calendar/$UID
$XDG_DATA_HOME defaults to $HOME/.local/share, but you could override
that in e-calendar-factory's environment. That would, however, store
-all- local calendars at the custom location.
So would the following work for Hans?
- move /home/hansdej/.SyncEvolution/Calendar/calendar.ics
to /home/hansdej/.local/share/evolution/calendar/syncevolution.ics
- change evolutionsource to "local:syncevolution.ics"; this will be
used as URI
Or is a GConf entry absolutely necessary?
In that case I guess Hans will have to create a calendar via the
Evolution UI, then copy his data over into that file and then use the
URI or calendar named configured via Evolution in SyncEvolution's
evolutionsource.
--
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:41 p.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems? Evolution 2.32?
Op dinsdag 22 maart 2011 15:08:57 schreef Patrick Ohly:
On Di, 2011-03-22 at 12:14 +0000, Matthew Barnes wrote:
> On Tue, 2011-03-22 at 08:13 +0100, Patrick Ohly wrote:
> > Matthew, is it still possible to specify absolute file locations with
> > the new local: prefix in Evolution 2.32?
>
> We do support specifying a custom .ics file for calendars, but currently
> this has to be configured through Evolution and the custom file location
> is stored in the XML blob in GConf (/apps/evolution/calendars/sources).
> There's no way to specify it with the URI alone.
I suppose I must reread our older mail thread about config changes
coming in 3.0, but let shoot of a quick question anyway: further config
changes are coming in 3.0 that will replace this XML blob, right?
> I'll also note that "local:$UID" calendar URIs are *somewhat*
flexible
> in that the file location is defined as:
>
> $XDG_DATA_HOME/evolution/calendar/$UID
>
> $XDG_DATA_HOME defaults to $HOME/.local/share, but you could override
> that in e-calendar-factory's environment. That would, however, store
> -all- local calendars at the custom location.
So would the following work for Hans?
- move /home/hansdej/.SyncEvolution/Calendar/calendar.ics
to /home/hansdej/.local/share/evolution/calendar/syncevolution.ics
- change evolutionsource to "local:syncevolution.ics"; this will be
used as URI
Hi,
Patrick guessed right about me using Debian tesing and a recent evolution upgrade.
From your replies -with hindsight- I deduced my issue is of similar character as mentioned
in the "Issues with evolution 2.32 and syncevolution 1.1.1a"-thread.
your replies and a further look into that thread set me on track to a presently somewhat
working solution.
1) Though I use KDE on a daily basis, I fired up the evolution UI, added a
"testagenda" calendar and set
/home/hansdej/.SyncEvolution/Calendar/calendar.ics
as its source-file. Then quit the evolution-UI again.
2) run syncevolution from the commandline without any arguments: somewhere this printed:
Evolution Calendar = evolution-calendar:
...
testagenda (local:/1300890094.24610.0@chrysemys)
...
3) run (a script containing:)
syncevolution --configure \
--source-property type=text/calendar \
--source-property evolutionsource=local:/1300890094.24610.0@chrysemys \
--source-property sync=slow \
--source-property uri=Calendar \
${peer} calendar
And voilá my N900 calendar is updated from the local ics-file again, thanks.
There is a hickup I wonder about though.
After I applied it to my actual calendar again, things seem to work though I get a curious
error message and I wonder whether I should worry about it?
An ERROR: "remote, status 512" as you can see below.
(To me it smells like some kind of timeout on the N900 or in the Bluetooth-connection, but
that is just a wild speculation)
/begin{*********************Commandline snippet*****************}
hansdej@chrysemys]>syncevolution draugen
[INFO] addressbook: inactive
[INFO] calendar+todo: inactive
[INFO] memo: inactive
[INFO] todo: inactive
[INFO] Server sending SAN
Local data changes to be applied remotely during synchronization:
*** calendar ***
no changes
[INFO] calendar: started
[INFO] calendar: started
[INFO] calendar: started
[INFO] calendar: started
[INFO] calendar: started
[INFO] calendar: started
[INFO] calendar: inactive
[ERROR] remote, status 512
[INFO] calendar: inactive
[ERROR] remote, status 512
Synchronization failed, see
/home/hansdej/.cache/syncevolution/draugen-2011-03-23-17-26/syncevolution-log.html for
details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 16 |
| disabled, 45 KB sent by client, 505 KB received |
| 0 client item(s) discarded |
| 16 server item(s) discarded |
| 0 item(s) duplicated |
| 888 item(s) matched |
| item(s) in database backup: 1029 before sync, 1029 after it |
| remote, status 512 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Wed Mar 23 17:26:24 2011, duration 2:15min |
| remote, status 512 |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: remote, status 512
Data modified locally during synchronization:
*** calendar ***
no changes
[ERROR] command line execution failure
\end{*********************Commandline snippet*****************}
Or is a GConf entry absolutely necessary?
In that case I guess Hans will have to create a calendar via the
Evolution UI, then copy his data over into that file and then use the
URI or calendar named configured via Evolution in SyncEvolution's
evolutionsource.
2:19 p.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems? Evolution 2.32?
On Wed, 2011-03-23 at 17:41 +0100, Hans de Jonge wrote:
Op dinsdag 22 maart 2011 15:08:57 schreef Patrick Ohly:
> I suppose I must reread our older mail thread about config changes
> coming in 3.0, but let shoot of a quick question anyway: further config
> changes are coming in 3.0 that will replace this XML blob, right?
I think I missed Patrick's reply, but as I clarified for him on a
different mailing list thread, the config changes missed 3.0 and are
targeted now for 3.2. But yes, the primary goal is to replace the XML
blobs in GConf with easy-to-read/easy-to-edit key files that live within
your evolution data directory.
I'm also doing away entirely with using URIs to reference configured
calendars, address books, etc. It finally dawned on me that the way
we've been using these URIs since about forever is actually broken and,
in my view, is just making things needlessly complex. This issue with
the file backend is a perfect example.
Instead, these "ESources" as we call them, which describe and hold
settings for a calendar or address book (and soon, mail accounts), will
be identified exclusively by the unique identifier string (UID) they
already have.
I'll be introducing a global singleton registry object to hold all these
ESources, which can be queried in a number of ways including by UID.
End result will hopefully be a much simpler and more robust account
management design for E-D-S than what we've been living with.
> So would the following work for Hans?
>
> - move /home/hansdej/.SyncEvolution/Calendar/calendar.ics
> to /home/hansdej/.local/share/evolution/calendar/syncevolution.ics
> - change evolutionsource to "local:syncevolution.ics"; this will be
> used as URI
Not quite. You'll need to make up a UID string for the calendar, let's
say "syncevolution", and then insert an XML <source> element in the
appropriate blob in the /apps/evolution/calendar/sources GConf key.
Then within that <source> element, add a child element like so:
<source uid="syncevolution" ...>
<property name="custom-file"
value="/path/to/syncevolution.ics"/>
</source>
Then the URI for the calendar would be "local:syncevolution".
Yes it's a PITA right now, and for this particular use case could be
viewed by some as a regression from the earlier file:// URIs. It's best
to configure this through Evolution, or at least programmatically using
the ESource/ESourceGroup APIs that can spit out the XML for you.
FWIW, after the planned changes have landed for 3.2, configuration for
this same calendar will be as follows:
You'll have a file ~/.local/share/evolution/sources/syncevolution with
contents that look something like:
[Data Source]
DisplayName=My SyncEvolution Calendar
Parent=local
[Calendar]
Color=#rrggbb
Enabled=true
WritableHint=true
[Local Backend]
CustomFile=/path/to/syncevolution.ics
The key file's basename becomes the ESource's unique ID;
"syncevolution"
in this case.
Hope all this rambling helps...
Matthew Barnes
11:55 a.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
Hans de Jonge <hans@...> writes:
Op dinsdag 15 maart 2011 11:26:38 schreef Patrick Ohly:
> Hello folks!
>
> Debian users have tried out installing more recent SyncEvolution
> packages and ran into issues that apply to all distros shipping
> SyncEvolution. I'd like to raise awareness of these issues and discuss
> how to solve them.
Hello
and yes, I run into the same problem.
My question is: How to solve this?
"First ERROR encountered: Error allocating calendar"
2:46 p.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
Am Mittwoch, den 06.04.2011, 15:55 +0000 schrieb Michael Luthardt:
Hans de Jonge <hans@...> writes:
>
>
> Op dinsdag 15 maart 2011 11:26:38 schreef Patrick Ohly:
> > Hello folks!
> >
> > Debian users have tried out installing more recent SyncEvolution
> > packages and ran into issues that apply to all distros shipping
> > SyncEvolution. I'd like to raise awareness of these issues and discuss
> > how to solve them.
Hello
and yes, I run into the same problem.
My question is: How to solve this?
"First ERROR encountered: Error allocating calendar"
I got a similar error: First ERROR encountered: Error allocating memo
list
I read several mails according the evolution 2.32.2 and syncevolution
1.1.1a issue, but did not find any fix.
syncevolution 1.1.99.3-2
evolution 2.32.2-2
regards
bjoern
--
jabber: bjo(a)schafweide.org
bjo.nord-west.org | nord-west.org | freifunk-ol.de
3:11 a.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
On Mi, 2011-04-06 at 19:46 +0100, Bjoern Franke wrote:
Am Mittwoch, den 06.04.2011, 15:55 +0000 schrieb Michael Luthardt:
> Hans de Jonge <hans@...> writes:
>
> >
> >
> > Op dinsdag 15 maart 2011 11:26:38 schreef Patrick Ohly:
> > > Hello folks!
> > >
> > > Debian users have tried out installing more recent SyncEvolution
> > > packages and ran into issues that apply to all distros shipping
> > > SyncEvolution. I'd like to raise awareness of these issues and
discuss
> > > how to solve them.
>
>
> Hello
> and yes, I run into the same problem.
> My question is: How to solve this?
>
> "First ERROR encountered: Error allocating calendar"
I got a similar error: First ERROR encountered: Error allocating memo
list
I read several mails according the evolution 2.32.2 and syncevolution
1.1.1a issue, but did not find any fix.
See the mails posted in this thread earlier:
http://www.mail-archive.com/syncevolution@syncevolution.org/msg02105.html
And in particular the email where Hans describes how he solved the
problem:
http://www.mail-archive.com/syncevolution@syncevolution.org/msg02108.html
If you have an easier description how to solve it, please write it up
and share it either here or in the syncevolution.org Wiki.
--
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.
6:56 p.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
Hi,
See the mails posted in this thread earlier:
http://www.mail-archive.com/syncevolution@syncevolution.org/msg02105.html
And in particular the email where Hans describes how he solved the
problem:
http://www.mail-archive.com/syncevolution@syncevolution.org/msg02108.html
I read both messages. I'm a bit confused, because syncevolution seems to
see the sources:
Evolution Address Book = Evolution Contacts = evolution-contacts:
Persönlich (local:/system) <default>
Evolution Calendar = evolution-calendar:
Persönlich (local:/system) <default>
Geburts- und Jahrestage (contacts:///)
Evolution Task List = Evolution Tasks = evolution-tasks:
Persönlich (local:/system) <default>
Evolution Memos = evolution-memos:
Persönlich (local:/system) <default>
I tried to use evolutionsource=local:/1302191375.17395.0@mytilus but it
didnt work.
regards
Bjoern
--
jabber: bjo(a)schafweide.org
bjo.nord-west.org | nord-west.org | freifunk-ol.de
2:18 a.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
On So, 2011-04-10 at 23:56 +0100, Bjoern Franke wrote:
Hi,
> See the mails posted in this thread earlier:
> http://www.mail-archive.com/syncevolution@syncevolution.org/msg02105.html
>
> And in particular the email where Hans describes how he solved the
> problem:
> http://www.mail-archive.com/syncevolution@syncevolution.org/msg02108.html
>
I read both messages. I'm a bit confused, because syncevolution seems to
see the sources:
Evolution Address Book = Evolution Contacts = evolution-contacts:
Persönlich (local:/system) <default>
Evolution Calendar = evolution-calendar:
Persönlich (local:/system) <default>
Geburts- und Jahrestage (contacts:///)
Evolution Task List = Evolution Tasks = evolution-tasks:
Persönlich (local:/system) <default>
Evolution Memos = evolution-memos:
Persönlich (local:/system) <default>
I tried to use evolutionsource=local:/1302191375.17395.0@mytilus but it
didnt work.
What other values of "evolutionsource" did you try earlier?
It seems that there were also bugs in the handling of the local:/system
URI that were only fixed in Evolution 3.0. Exact effect unknown. I
suggest that you leave "evolutionsource" empty, the default should work.
If not, then Evolution itself should be in unable to open these
databases.
--
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:15 p.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
Hi,
Am Montag, den 11.04.2011, 08:18 +0200 schrieb Patrick Ohly:
What other values of "evolutionsource" did you try earlier?
I left evolutionsource empty, but because it did not work, I tried the
"On your computer"-value from the memo-source in the gconf XML blob.
It seems that there were also bugs in the handling of the
local:/system
URI that were only fixed in Evolution 3.0. Exact effect unknown. I
suggest that you leave "evolutionsource" empty, the default should work.
If not, then Evolution itself should be in unable to open these
databases.
If I leave it empty, it does not work either. But evolution itself has access to the
addressbook, calendar etc.
regards
Bjoern
--
jabber: bjo(a)schafweide.org
bjo.nord-west.org | nord-west.org | freifunk-ol.de
8:16 p.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
Hi,
If I leave it empty, it does not work either. But evolution itself has access to the
addressbook, calendar etc.
I found the solution for my problem:
The error was caused by some old libaries of Evolution 2.28 and 2.30. If
you upgrade Evolution in Debian Unstable, the new libedataserver,
libecal etc. libaries are installed additionally and the old ones get
not deleted.
If you remove them, the sync works fine.
regards
Björn
--
jabber: bjo(a)schafweide.org
bjo.nord-west.org | nord-west.org | freifunk-ol.de
8:36 a.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
On Di, 2011-04-12 at 01:16 +0100, Bjoern Franke wrote:
> If I leave it empty, it does not work either. But evolution
itself has access to the addressbook, calendar etc.
I found the solution for my problem:
Good!
The error was caused by some old libaries of Evolution 2.28 and 2.30.
If
you upgrade Evolution in Debian Unstable, the new libedataserver,
libecal etc. libaries are installed additionally and the old ones get
not deleted.
If you remove them, the sync works fine.
Did you use the SyncEvolution binaries from syncevolution.org? I
remember vaguely that this came up before, and if my memory doesn't fail
me, then the syncevolution.org binaries should open the correct
ecal/ebook libraries.
I wonder if EDS/Evolution >= 2.30 distro packages should have a conflict
with libecal/ebook < 2.30, to prevent such broken combination of
packages. David, what do you think?
--
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.
6:20 a.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
On Thu, 14 Apr 2011 14:36:47 +0200, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
I wonder if EDS/Evolution >= 2.30 distro packages should have a conflict
with libecal/ebook < 2.30, to prevent such broken combination of
packages. David, what do you think?
I don't really understand how EDS can use a different version of the
libraries than it was linked against; I suppose it could be doing some
dlopen business. I think I'd have to know more before I commented. There
are good reasons to keep libraries co-installable in general. On the
other hand, if the new EDS packages don't work with the old libraries
installed, that is a bug, and should be reported.
Sorry I can't be more helpful, I don't know the Evolution ecosystem at
all beyond its interaction with syncevolution.
d
9:08 a.m.
New subject: [SyncEvolution] packagers: system upgrade? file backend problems?
On Mo, 2011-04-18 at 11:20 +0100, David Bremner wrote:
There
are good reasons to keep libraries co-installable in general. On the
other hand, if the new EDS packages don't work with the old libraries
installed, that is a bug, and should be reported.
That is indeed the case. I filed bug#623216 (attached).
--
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.
3604
days inactive
3638
days old
syncevolution@synevolution.org
21 comments
8 participants
participants (8)
-
Bjoern Franke -
David Bremner -
David Bremner -
Frederik Elwert -
Hans de Jonge -
Matthew Barnes -
Michael Luthardt -
Patrick Ohly