Re: [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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [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: b...@schafweide.org bjo.nord-west.org | nord-west.org | freifunk-ol.de ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [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 + 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [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 ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] packagers: system upgrade? file backend problems?
Am Mittwoch, den 06.04.2011, 15:55 + 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: b...@schafweide.org bjo.nord-west.org | nord-west.org | freifunk-ol.de ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] packagers: system upgrade?
On Fr, 2011-03-18 at 15:01 +, Patrick Ohly wrote: On Fr, 2011-03-18 at 14:57 +, David Bremner wrote: On Tue, 15 Mar 2011 13:27:03 +0100, Patrick Ohly patrick.o...@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.o...@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.o...@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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [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 +, 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
Re: [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 ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] packagers: system upgrade? file backend problems? Evolution 2.32?
On Mo, 2011-03-21 at 22:51 +, 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [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/hansdejsyncevolution 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
Re: [SyncEvolution] packagers: system upgrade?
On Fr, 2011-03-18 at 14:57 +, David Bremner wrote: On Tue, 15 Mar 2011 13:27:03 +0100, Patrick Ohly patrick.o...@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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] packagers: system upgrade?
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 ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] packagers: system upgrade?
On Di, 2011-03-15 at 11:19 +, 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
