[SyncEvolution] bug tracking: bugzilla.moblin.org -> bugzilla.meego.com
by Patrick Ohly
Hello!
Bug tracking of most Moblin projects has moved to bugzilla.meego.com
(BMC). SyncEvolution itself is an upstream project that is used inside
Moblin and MeeGo and has not moved yet. At some point
bugzilla.moblin.org (MB) will be turned into read-only mode, so we have
to move elsewhere.
We debated whether we should move to BMC or set up a bug tracker at
syncevolution.org. In the end we decided to move to BMC because it
avoids the work of maintaining a separate bug tracker instance and
simplifies our QA work.
We'll start the migration by moving the open feature requests first.
Until further notice please keep filing bugs against the current release
in MB.
The syncevolution-issues mailing list already gets copies of issue
reports from both MB and BMC. Those who prefer to configure their email
notifications individually can create an account on meego.com (not
bugzilla.meego.com!) and use it in BMC to "watch" the
syncevolution-bugs(a)meego.bugs pseudo user. There are other such pseudo
users for the different components.
When referring to bugs, be it in emails or commits, please use MB #123
for the old tracker and BMC #456 for the new one, to avoid confusion.
--
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 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, 9 months
[SyncEvolution] about 'refresh-from-client' mode
by Zhu, Yongsheng
Hi, Thomas
Our nightly results show us that in 'refresh-from-client' mode, if a client doesn't have any data and initiates a sync with empty data, server won't wipe out its data. Is this your expected behavior? Thanks.
Regards,
Yongsheng
10 years, 9 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
10 years, 9 months
[SyncEvolution] Database error 10500
by Peter Lipp
Hi,
syncevolution was working perfectly, until I upgraded to evolution
2.30.0.1 and SyncEvolution 1.0beta2a, both built "On site". Now I keep
getting a mysterious 10500... Any suggestions on how to proceed?
Peter
--
---
IAIK, Graz University of Technology
Inffeldgasse 16a
A-8010 Graz
Tel: +43 316 873 5513
Fax: +43 316 873 10 5513
www.iaik.tugraz.at
10 years, 9 months
[SyncEvolution] dynamic discovery of sync service in (W)LAN
by Patrick Ohly
Hi!
In the current "direct sync" work we focus on Bluetooth for one reason
alone: it is standardized, at least to a large extend. The specific
settings for a device differ, but the transport is the same for all of
them.
>From what I have heard so far, communication via USB requires
device-specific setup. For synchronization via wireless, there are two
options:
* ad-hoc direct between device and PC: would work without any
additional hardware, but uncommon
* devices log into the same W-LAN: that's how devices typically
connect to the Internet, but they won't know about each other,
so direct sync without manual configuration becomes harder
One possible solution for the second problem is DNS Service Discovery,
as used by Apple Bonjour and Avahi on Linux: http://www.dns-sd.org/
I checked, so far no-one has bother to add OMA DS/SyncML to the list of
services which can be discovered like that. There are several
proprietary sync services listed, though.
There are several data items which would have to be "discoverable":
* IP address of host
* port
* path (for HTTP POST)
* unique SyncML device ID (to distinguish multiple servers)
* information about URIs
IP address, port and path is something also used by existing services.
The SyncML specific parts are those that we have to define in more
detail. For example, how do we describe that URI "addressbook" is for
"contacts"? How do we describe multiple address books, for example one
for private use and company?
This kind of self-description is not part of SyncML, leading to the
current complexity involved in configuring clients and servers
correctly.
Just food for thought... I'm not ready to suggest a specific solution,
but wanted to write down my thoughts so far.
--
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 years, 9 months
[SyncEvolution] Trying to understand Syncevolution/Funambol interplay
by martin f krafft
Dear syncevolution community,
I just encountered syncevolution in my quest for a scalable solution
to synchronise contacts and events between my E71 and the new N900
(Maemo). Eventually I'd even like to offer synchronisation and
integration with a groupware suite to a local non-profit, but I am
a far way from that.
I got Funambol working and synchronised the N900 with it, using
syncevolution. I then installed Evolution and used syncevolution to
synchronise it, and while it downloaded all my contacts, it seems
like a lot of detail was lost. For instance, some phone numbers
didn't show up in Evolution, and several contacts didn't have
addresses anymore. I think this may be due to the VCard feature of
specifying e.g. Home vs. Work addresses.
I would like to find out how to track down the problem, but first
I need to understand how this SyncML stuff works. It seems like the
protocol does not just negotiate data records, but that it actually
knows about contacts and the individual VCard fields.
And then there is Funambol, which stores individual data with a type
ID field that I don't know how to translate (yet).
So I am wondering how and why some of the details of the contacts
aren't properly synchronised. This means I need to understand
exactly how the parts fit and work together. Is there a kind soul
out there ready to explain this to me?
What docs should I read?
Or does someone know why some details are being lost during
synchronisation, or even better: how to work around that?
Thanks,
--
martin | http://madduck.net/ | http://two.sentenc.es/
because light travels faster than sound,
some people appear to be intelligent,
until you hear them speak.
spamtraps: madduck.bogus(a)madduck.net
10 years, 9 months
[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.
10 years, 9 months
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.
10 years, 9 months
