[SyncEvolution] How to select the evolution target calendar
by Matthias Urlichs
Hello,
I have one small problem: I cannot select which local Evolution calendar
SyncEvolution actually talks to.
Apparently it uses the first entry in
the /apps/evolution/calendar/sources gconf entry that it can find. Since
the order of these entries isn't changeable and I need to separate
"work" from "home" calendar entries (with separate mobiles to sync to
…), I'd like some way to change that.
Either this is not possible yet, or I'm blind and didn't find it in the
documentation …?
Otherwise, thanks for the excellent tool; it works with our Oracle
calendar like a charm (using the values in the Oracle branch).
-- Matthias
10 years, 9 months
[SyncEvolution] No UID's in vcards
by Christoph Kaulich
Hello,
I am trying to use syncevolution together with egroupware 1.6.003.
Syncing calendar and todos is working fine, but the vcards does not contain a
UID.
I am using the file backend to use the data in Kontact, so I really need the
UID in there. I I look inthe debug messages from egroupware the cards contain
UID's and syncing them to Kontact via groupdav, they also contain UID's,. Is
there anything I can do in syncevolution about that?
Thanks
Christoph
--
GNS mbH
Dipl.-Ing.
Christoph Kaulich
Am Gaußberg 2
38114 Braunschweig
http://www.gns-mbh.com
Tel.: ++49 (0) 531 / 8 01 12-17
Fax : ++49 (0) 531 / 8 01 12-79
Mobil: ++49 (0) 175 / 2 68 57 05
mailto:kaulich@gns-mbh.com
Sitz und Amtsgericht Braunschweig HRB 4004
Steuernummer 14/203/31601
VAT-Id. DE173536746
Geschäftsführer: Stefan Hanson, Klaus Radtke, Claudius Schöne
10 years, 12 months
[SyncEvolution] Alarms in the calendar: Evolution vs. vcal
by Tino Keitel
Hi,
I use www.mobical.net as my SyncML server to sync 2 computers with
Evolution and my mobile phone (Nokia E55). It works pretty well, except
for alarms in appointments.
If I create an appointment in evolution, the alarm is lost on the
SyncML server and on the phone.
If I create an appointment on the phone, the alarm is shown correctly
on www.mobical.net, but in Evolution it looks like this:
BEGIN:VEVENT
SUMMARY:Test
DESCRIPTION:Testdetail
DTSTART:20100317T070000Z
DTEND:20100317T080000Z
UID:20100316T213421Z-1945-1000-1-72@x61
DTSTAMP:20100316T213421Z
CREATED:20100316T213421Z
LAST-MODIFIED:20100316T213421Z
BEGIN:VALARM
TRIGGER;VALUE=DATE-TIME:20100317T065500Z
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for ACTION
property. Removing entire property:
X-EVOLUTION-ALARM-UID:20100316T213421Z-1945-1000-1-73@x61
END:VALARM
END:VEVENT
The Evolution GUI shows a customized alarm and "Unknown action to be
performed at Wed 03/17/2010 07:55".
I think the problem is caused by the SyncML server and the phone not
supporting iCalendar 2.0, but only vCalendar. Is there a way to get
correct sync of alarms nevertheless?
Regards,
Tino
11 years
[SyncEvolution] status 2010-03-25
by Patrick Ohly
Hello!
Here's another summary of where we are - and have been in the past
weeks...
SyncEvolution 1.0 keeps us busy. I mentioned a 1.0 beta 3 last week and
already made a pre-release available:
1.0beta2a+20100319+SE+15d4589+SYSYNC+0e94c06 in
http://downloads.syncevolution.org/tmp/
We got some feedback on that from Intel QA and in addition, try to get
one last feature in: command line tool as D-Bus client of the
syncevo-dbus-server (MB #5043). This work is not completed yet, so we
are delaying 1.0 beta 3 a bit so that we can really say that it is
"feature complete" when it goes out.
In terms of feedback, please try out direct sync and automatic sync.
These are the new features in 1.0 which might still have bugs and
usability problems.
MeeGo 1.0 "day one" (= code available) is just around the corner. A more
detailed architecture of it will be also made available at that time.
Without getting ahead of that announcement let me just say that I would
be surprised if SyncEvolution wasn't in MeeGo 1.0...
Development (roughly by week, last week backward):
* Yongsheng: started work on moving command line into D-Bus server
(MB #5041/5042/5043), better status code for InfoRequest timeout
(MB #9636), fixed segfault in autosync code
* Congwu: ongoing work on automatic test script for phones (MB
#9862), dealt with a user report of duplicated calendar events
on the N900 when syncing directly (MB #10224)
* Patrick: ww12 snapshot (including external release so that users
can confirm some issues), finished server suspend/resume
improvements and testing (MB #2425), untagged snapshots now get
a unique version derived from base version and git commit hashes
* Jussi: additional and improved error descriptions, automatic
sync switch, improved device config UI
* Yongsheng: automatic sync in backend (MB #6378), localized
notifications for automatic sync (MB #10000), started to move
command line into D-Bus server (MB #5043)
* Congwu: SAN 1.1 support, ready to be merged by Synthesis; found
and solved a bug in libsynthesis when forcing slow sync for a
virtual source (MB #9907), Ovi.com interoperability testing,
fixes for valgrind errors in OBEX transport, create config in
OBEX SyncML client automatically (MB #6175)
* Patrick: temporary workaround for Qt D-Bus binding issues,
hardening the server's support for suspend/resume (required
adding blob support, analysing/reporting/fixing bugs in
libsynthesis and SyncEvolution), found and fixed regression in
HTTP server mode introduced by recent SAN changes, finished
command line support for shared configs (MB #8048),
libbluetooth3 incompatibility in syncevolution.org binaries (MB
#9289), fix for SAN 1.2->1.1 fallback, fix incorrect D-Bus
shutdown when server is started twice (MB #9991)
* Jussi: fixed two segfaults and some other bugs in sync-UI
* Yongsheng: automatic sync via polling (MB #6378), adapt list of
Bluetooth peers and templates at runtime
* Congwu: helped identifying direct sync issues (MB #9902), Nokia
N7210c template improvements (MB #9907), SAN 1.0 support (MB
#9312)
* Patrick: several server improvements (better testing, handling
resent messages in HTTP server), logdir naming changed in case
of collision (MB #9759), last-minute libbluetooth compatibility
fix for 1.0 beta 2 and better packaging (MB #9289/#9811),
platform workarounds (libical memory bug, Mozilla NSS
initialization), Evolution calendar change tracking fix (minor
race condition), fix for error when logdir doesn't exist, notify
sync-ui when templates change, CouchDB workaround (MB #7877),
improved reporting of "syncevolution died unexpectedly" (MB
#9844)
* Jussi: double-free fix (MB #9869), error message for
"syncevolution died unexpectedly", Bluetooth Panel integration
in Moblin
* Patrick: libical memory corruption workaround, avoid CouchDB
Evolution backend (MB #7877), improved packaging on
syncevolution.org (declare conflicts with system SyncEvolution
MB #9811, Bluetooth compatibility layer MB#9289), better
reporting of segfaults and other aborted syncs (MB #9844), fix
for recently introduced crash on Debian Etch (Mozilla NSS init),
reduced size of logs (MB #8092), avoid Horde mistreating us as a
broken Funambol client (deviceId, MB #9347), preventSlowSync
enabled by default (MB #2416), increased maxMsgSize (was too
slow for large DevInf), completed transition from
text/x-calendar to text/x-vcalendar, more fix for virtual data
sources (type check, segfault MB #9737, name collisions and
aliases MB #9664), more intelligent handling of session dirs (MB
#7708), delay database dump and comparison also in clients (MB
#7710), new SyncSource::isEmpty() API (MB #7708), minimize
database accesses by caching result of listAllItems() (MB #7708)
* Jussi: Ubuntu Hardy GTK workarounds, InfoRequest implementation
--
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 years
Re: [SyncEvolution] Wiki on syncevolution.org
by Patrick Ohly
On Wed, 2010-03-31 at 14:27 +0100, Shaver, Michael R wrote:
> > I don't expect that much traffic, but I suspect that it'll be necessary
> > for authenticated users to create new pages. Would that be possible with
> > option #2?
>
> Yes, authenticated users could create new pages. We could make it very easy
> for them to see the create content link as well, rather then go through the
> normal admin menus.
I'm tempted to give that a try. Without a chance to see it live it is a
bit hard to determine whether it'll work for us, though. Can you set
this up for us?
Can and should we limit this expanded editing to a specific namespace,
like http://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.
11 years
Re: [SyncEvolution] Wiki on syncevolution.org
by Patrick Ohly
Hello Mike!
Let's continue the discussion on the public mailing list. After all,
these are the people who hopefully will use it more than we ourselves
will ;-)
On Wed, 2010-03-31 at 01:01 +0100, Shaver, Michael R wrote:
> I think there are a few possibilities here.
>
> 1. Full wiki solution (MediaWiki)
> - Domain would be: http://wiki.syncevolution.org
> - There is an extension for sharing the user accounts between MediaWiki
> and drupal. It's not perfect though? Maybe this level of integration isn't
> necessary?
>
> 2. Build some simple wiki like functionality into Drupal.
> - pages would all be within the syncevolution domain
> - access would be for any authenticated user
> - revisions for page would be set, so could roll back
> - markup can be similar to wiki
> - linking to new pages isn't as easy
> - some find full wiki markup a bit of a pain though, so this could be
> easier?
>
> If you think the wiki could get a fair amount of traffic and use, I would go
> with option #1. If it seems more like just a few pages needed open editing
> rights, then option #2 is probably easier to setup and maintain.
I don't expect that much traffic, but I suspect that it'll be necessary
for authenticated users to create new pages. Would that be possible with
option #2?
--
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 years
[SyncEvolution] packaging 1.0: libnotify + localization
by Patrick Ohly
Hello!
For those maintaining packages of 1.0, here are two more items for the
README.packagers file, just added to the source:
- libnotify is needed by the syncevo-dbus-server, although
--disable-notify can be used to avoid that.
- Localization data is shared between sync-ui and syncevo-dbus-server
and thus needs to be packaged with the core SyncEvolution.
The reason for both is the automatic sync in the background, which pops
up localized messages when syncs start, end or fail.
Here are the older entries from that file:
- for good time zone support, libsynthesis must have access to
either libical or libecal
- direct sync with phones depends on bluez and openobex
- GNOME Bluetooth Panel needs libgnome-bluetooth-dev *AND*
--enable-gnome-bluetooth-panel
- either glib or libnss should be available, so that
SyncEvolution can use SHA-256 hashes instead of a
weaker built-in algorithm for hashes in the database dump
.ini files
--
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 years
[SyncEvolution] sync-ui segfault with Ubuntu AMD64
by Steven Redlich
There is a thread on Ubuntu's launchpad detaining problems with sync-ui on
AMD64 using Ubuntu 9.10.
https://bugs.launchpad.net/ubuntu/+source/syncevolution/+bug/447150
After some reading here, I've added the syncevolution repositories and
installed some dbg versions of libraries; aptitude said I have the latest
version of sync-ui and syncevolution after trying both these repositories.
deb http://downloads.syncevolution.org/apt stable main
deb http://downloads.syncevolution.org/apt unstable main
Here's my latest backtrace run under gdb.
$ gdb sync-ui
...
(gdb) run
Starting program: /usr/bin/sync-ui
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff458973b in IA__g_type_name (type=<value optimized out>)
at /build/buildd/glib2.0-2.22.3/gobject/gtype.c:3056
3056 /build/buildd/glib2.0-2.22.3/gobject/gtype.c: No such file or directory.
in /build/buildd/glib2.0-2.22.3/gobject/gtype.c
(gdb) bt
#0 0x00007ffff458973b in IA__g_type_name (type=<value optimized out>)
at /build/buildd/glib2.0-2.22.3/gobject/gtype.c:3056
#1 0x00007ffff4e25065 in build_specialization_name (container=<value
optimized out>, num_types=14,
types=0x7170c0) at dbus-gtype-specialized.c:239
#2 lookup_or_register_specialized (container=<value optimized out>,
num_types=14, types=0x7170c0)
at dbus-gtype-specialized.c:423
#3 0x00007ffff4e252bc in dbus_g_type_get_struct (container=0x412ec3
"GValueArray",
first_type=140737488346744) at dbus-gtype-specialized.c:525
#4 0x000000000040dc62 in ?? ()
#5 0x00007ffff42b29eb in IA__g_ptr_array_foreach (array=0x742660,
func=0x40dbb0, user_data=0x0)
at /build/buildd/glib2.0-2.22.3/glib/garray.c:818
#6 0x000000000040a358 in ?? ()
#7 0x000000000040ee0e in ?? ()
#8 0x000000000040effa in ?? ()
#9 0x00007ffff4bdceba in ?? () from /lib/libdbus-1.so.3
#10 0x00007ffff4bdf0ff in dbus_connection_dispatch () from
/lib/libdbus-1.so.3
#11 0x00007ffff4e17bd5 in message_queue_dispatch (source=<value optimized
out>,
callback=<value optimized out>, user_data=<value optimized out>) at
dbus-gmain.c:101
#12 0x00007ffff42d8bce in g_main_dispatch (context=0x648980)
at /build/buildd/glib2.0-2.22.3/glib/gmain.c:1960
#13 IA__g_main_context_dispatch (context=0x648980) at
/build/buildd/glib2.0-2.22.3/glib/gmain.c:2513
#14 0x00007ffff42dc598 in g_main_context_iterate (context=0x648980,
block=<value optimized out>,
dispatch=<value optimized out>, self=<value optimized out>)
at /build/buildd/glib2.0-2.22.3/glib/gmain.c:2591
#15 0x00007ffff42dc9f5 in IA__g_main_loop_run (loop=0x8b3170)
at /build/buildd/glib2.0-2.22.3/glib/gmain.c:2799
#16 0x00007ffff76f6177 in IA__gtk_main () at
/build/buildd/gtk+2.0-2.18.3/gtk/gtkmain.c:1218
#17 0x0000000000405f8d in ?? ()
#18 0x00007ffff3f4cabd in __libc_start_main (main=<value optimized out>,
argc=<value optimized out>,
ubp_av=<value optimized out>, init=<value optimized out>, fini=<value
optimized out>,
rtld_fini=<value optimized out>, stack_end=0x7fffffffe398) at
libc-start.c:220
#19 0x0000000000405e79 in ?? ()
#20 0x00007fffffffe398 in ?? ()
#21 0x000000000000001c in ?? ()
#22 0x0000000000000001 in ?? ()
#23 0x00007fffffffe653 in ?? ()
#24 0x0000000000000000 in ?? ()
I've subscribed to the digest, so please trim any replies.
Thanks,
Steve
11 years
[SyncEvolution] device template naming
by Jussi Kukkonen
I have some questions on how to fine tune the device configuration (now
improved in jku branch).
I'm currently using the first part of device template fingerprint as the
name. That is currently not very user friendly but I'm not sure what
would be the right way fix that: Is there a reason why the "first
fingerprint" couldn't be 'Nokia 7210' instead of 'nokia_7210c'? If there
is, then we should probably add another "templateName" property...
Related question: how do you see the device templates growing from here?
I'm trying to figure out a good way to tell the user this:
"We think your device is 'Foo Bar'. ...."
Currently that's mostly going to look wrong even in the places where the
template is usable (e.g. another Nokia S40 phone would work but the
message incorrectly claims "We think your device is 'Nokia 7210c'".).
Thinking aloud, would this work:
* if template score is high enough:
"We think your device is 'Nokia 7210'. ..."
* if template score is lower but still acceptable:
"We think your device is 'Nokia 7210' or a similar device. ...."
* If highest template score is too low, or several templates have the
same score:
"We don't know what this device is exactly. ..."
A related issue is when should we start renaming/copying templates: if
the nokia_7210c template works for many S40 phones*, maybe we should
rename the template "Nokia S40 phone", and add phone templates that
symlink to the generic one -- or something like that anyway?
-Jussi
*) I think Nick left for vacation before he sent his test report, but
apparently people at Intel london office have informally tested quite a
few S40 phones with success...
11 years
