[Bug 20370] New: Build: Do not try to discover and use gtk-builder-convert
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=20370
Summary: Build: Do not try to discover and use
gtk-builder-convert
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: GTK UI
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: murrayc(a)murrayc.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-gtk-ui-bugs(a)meego.bugs
Estimated Hours: 0.0
Created attachment 7722
--> https://bugs.meego.com/attachment.cgi?id=7722
0001-Do-not-check-for-or-use-gtk-builder-convert.patch
gtk-builder-convert is really not something that should be used in a build
process. It should be for one-time conversion and then not used again. And the
build has no need to have both file formats anyway because it only uses
GtkBuilder format.
Keeping the libglade-format file requires people to edit that one, risking new
failures during the automatic conversion. I'm not sure if recent versions of
Glade even save in libglade format any more.
This will fix this Maemo build issue, though it's not important:
https://bugs.maemo.org/show_bug.cgi?id=7466
--------
Product: SyncEvolution
Component: GTK UI
MeeGo Release: unspecified
Severity: normal
Priority: Undecided
Keywords:
Status: NEW
Who: murrayc(a)murrayc.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=20370
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 6 months
[Bug 16074] New: Configuration of a service can not be stored (Done button has no respnse)
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=16074
Summary: Configuration of a service can not be stored (Done
button has no respnse)
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: caco3(a)ruinelli.ch
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
When selecting a service and open it for editing, the done button has no
action.
The terminal shows that there is an error:
--------------------
Traceback (most recent call last):
File "/opt/syncevolution/syncfe.py", line 565, in edit_server
self.init_server_edit()
File "/opt/syncevolution/syncfe.py", line 806, in init_server_edit
source_config["evolutionsource"] = base_list[idx][1]
IndexError: list index out of range
---------------------
Interestingly, if run as root, it works fine.
Looking for differences, I see that (if run as root), the following entry in
the config window is missing:
calendar+todo database
As a quick workaround, replace line 806-807 in syncfe.py with (see attachment):
---------------------
if(idx<0): #Workaround by George Ruinelli
print "index out of range"
else:
source_config["evolutionsource"] = base_list[idx][1]
self.sync.set_source_config(config, name, source_config)
---------------------
OS: Maemo 1.3
SyncEvolution: 0.9
syncevolution: 1.1.1-1
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 6 months
[MeeGo Projects - Bug 13513] New: Sync history tries to load the wrong file (no such file name)
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=13513
Summary: Sync history tries to load the wrong file (no such
file name)
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: Maemo 5
AssignedTo: ovek(a)debian.org
ReportedBy: dbet1(a)gmx.net
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-maemo5-bugs(a)meego.bugs
Estimated Hours: 0.0
HARDWARE MODEL (on what HW this bug is uncovered): Nokia N900
BUG DETAILED DESCRIPTIONS
===========================================================
EXACT STEPS LEADING TO PROBLEM:
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
===========================================================
1. doing a sync using the Synchronize! button
2. tap on the View Synchronization History button
3. choose the entry 10.02.2011 10:45:12 [Success]
4. the browser shows an error: file
/home/user/.cache/syncevolution/memotoo/2011-02-10-10-45/sysynclib_linux.html#H1
not found
EXPECTED OUTCOME:
===================
The synchronization history from 10.02.2011 14:45:12 is showing.
ACTUAL OUTCOME:
===================
Error message from the browser.
USER IMPACT:
===================
REPRODUCIBILITY:
always
=====================================
EXTRA SOFTWARE INSTALLED:
============================
OTHER COMMENTS:
===================
The name of the file on this directory is not sysynclib_linux.html, instead its
name is syncevolution-log.html.
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8 years, 6 months
[Bug 19432] New: CalDAV + Google: implement constant request rate
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=19432
Summary: CalDAV + Google: implement constant request rate
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
The Google calendar server starts sending 401 errors when too many requests are
sent. The current code detects that and then retries the same request after
increasing delays.
However, each new request is always sent immediately, and thus runs into the
same 401 error, and so on.
We should remember across requests that delays were necessary and thus sent
requests at a rate that the server considers acceptable, but not faster.
To reproduce the problem, try:
CLIENT_TEST_NUM_ITEMS=100 CLIENT_TEST_MODE=server CLIENT_TEST_SIMPLE_UID=1
CLIENT_TEST_UNIQUE_UID=1 CLIENT_TEST_SERVER=google-calendar
CLIENT_TEST_EVOLUTION_PREFIX=file:///tmp/test_ ./client-test
Client::Sync::eds_event::testManyItems
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: enhancement
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=19432
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 7 months
[Bug 17345] New: transcode PHOTO data = avoid contact rejections by phones
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=17345
Summary: transcode PHOTO data = avoid contact rejections by
phones
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
From: Patrick Ohly <patrick.ohly(a)intel.com>
Cc: syncevolution(a)syncevolution.org <syncevolution(a)syncevolution.org>
Subject: Re: [SyncEvolution] Contacts rejected by peer - PHOTO size and
encoding
Date: Mon, 18 Apr 2011 09:14:49 +0100 (18.04.2011 10:14:49)
On Fr, 2011-04-15 at 06:59 +0100, Hevï Guy wrote:
> Once I finally set-up Syncevolution 1.1.1-2 so that I could at least
> do a one-way refresh of "Contacts" to my Nokia N86 8MP, I found that
> certain contacts would not sync; The resulting comment in the GUI was:
> "There were 22 remote rejections". Has anybody else experienced this?
> More importantly, has anybody found a solution?
Hevï sent me his log files. There were two problems:
1. Some contacts had photos that were so large that the contact
exceeded the maximum contact size supported by the phone (for
example, 206653 bytes where only 102400 = 100KB allowed).
2. Other contacts with photo are sent, but the phone reports an
error (415 status).
Hevï, were other contacts with photos transferred? The log only contains
the problematic contacts, so I cannot tell.
Do you see a relevant difference between a contact that was transferred
with photo and one which wasn't? Photo size or encoding (PNG vs. JPG,
for example)? If unsure, please send me the saved vCard of a contact
which was transferred okay.
The underlying question is this:
* Should PHOTO data be transcoded as part of syncing? This is
necessary at least for case 1 above and might also help with
case 2.
It could be added, but that leads to further questions:
* How does SyncEvolution decide which kind of PHOTO data will be
accepted by the peer? Resolution, format, ...
* If a photo was transcoded, how will SyncEvolution deal with an
updated photo sent by the peer?
A. Overwrite photo locally: allows updating photos on the
peer, but implies that a potentially higher resolution
version of the same photo gets overwritten when only
some other properties were modified.
B. Always preserve local photo data: adding a photo on the
peer would be possible, but not updating it.
Possible answers:
* Only transcode if it is detected during a sync that photos had
problems.
* Hard-code certain profiles, match them to DevInf reported by
device (based on max item size, for example).
* Preserve local photo data if transcoding was necessary.
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: enhancement
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=17345
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 7 months
[Bug 19724] New: [webdav] syncURLs in the form of foo-%u-bar, rather than /foo/%u/bar don't work
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=19724
Summary: [webdav] syncURLs in the form of foo-%u-bar, rather
than /foo/%u/bar don't work
Classification: MeeGo Platform
Product: OS Middleware
Platform: ---
Version: 1.2
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: salvatore.iovene(a)linux.intel.com
ReportedBy: salvatore.iovene(a)linux.intel.com
QAContact: jingke.zhang(a)intel.com
CC: patrick.ohly(a)intel.com, syncevolution-bugs(a)meego.bugs,
ext-iekku.huttunen(a)nokia.com
Estimated Hours: 0.0
BUG DETAILED DESCRIPTIONS
===========================================================
After commit 0d34ad46a6384c33e7dd84542956362d76809319, URLs like foo-%u-bar
might not work, because the insertion of the username in the path is not done
right away, but during the discovery phase, at each step. This means that there
might be trouble during the URL normalization from neon.
--------
Product: OS Middleware
Component: SyncEvolution
MeeGo Release: 1.2
Severity: normal
Priority: Undecided
Keywords:
Status: NEW
Who: salvatore.iovene(a)linux.intel.com
Assigned To: salvatore.iovene(a)linux.intel.com
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=19724
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8 years, 7 months
[Bug 19665] New: shared credentials
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=19665
Summary: shared credentials
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
>From the "[SyncEvolution] configuration of CalDAV/CardDAV" mail thread:
We have "username", "password", "syncURL" properties. If "password" is
"-", then reading credentials looks up the password based on the given
username and the syncURL in the GNOME keyring (or soon, KWallet). The
"server" and "user" keys are used as search filter, with "server" equal
to the syncURL minus the method prefix (i.e., http:// and https://
stripped).
Storing a "password" not equal to "-" will automatically set the
password value in the keyring if its usage is enabled (on by default in
the D-Bus server, off in the command line).
Retrieving the config via D-Bus transparently retrieves the credentials
and sends them to the D-Bus client.
I'd like to extend this so that the username doesn't have to be know in
advance, and so that CalDAV and SyncML can refer to the same server
despite having different syncURLs.
Here's how:
"credentials = URI": Defines where credentials are stored. The empty
string (default) is the traditional approach.
"gnome://server=<server>[&user=<user>]" takes username and password from
the corresponding entry. "kde://" does the same for KWallet.
"keyring://" is an alias for the default keyring (depends on how the
binary was compiled and runtime environment). Saving a config will
always update the "credentials" property with the actual location.
Here are some use cases for this:
* The "google" and "google-calendar" configs will have
"credentials = keyring://server=google" set. In the case of
"google-calendar", both the sync and source configs have that.
That way all three configs use the same username/password
automatically. It forces command line users who do not want to
or can't use a keyring to configure with empty "credentials";
they can't share credentials.
* After configuring via the D-Bus interface, the command line will
automatically enable the right access method for the
credentials. It is no longer necessary to explicitly say
"syncevolution --keyring".
* A future extension would use either a different method or
additional parameters in the URI to define some other
authorization method. The current implementation must throw an
error when running into something it doesn't know.
Nothing needs to be done in the UI or the command line to support this.
The only changes will be in the current code which talks to the
keyring(s).
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: normal
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=19665
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 7 months
[Bug 19433] New: CalDAV + Google: incorrect 404 for GET
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=19433
Summary: CalDAV + Google: incorrect 404 for GET
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
>From a testManyItems test:
[INFO @google 00:03:16] @google/calendar: adding "030-phone meeting, 030-my
office"
[DEBUG @google 00:03:16] starting PUT
[DEBUG @google 00:03:17] update item status: <status 1.1, code 201, class 2,
Created>
[DEBUG @google 00:03:17] starting PROPFIND
[DEBUG @google 00:03:17] item
UNIQUE-UID-1308257075-030-UNIQUE-UID-1308257075-1234567890(a)dummy.ics = rev
63443940431
[DEBUG @google 00:03:17] starting GET
[DEBUG @google 00:03:18] resending VEVENT to get rid of VALARM
[DEBUG @google 00:03:18] starting PUT
[DEBUG @google 00:03:19] update item status: <status 1.1, code 204, class 2, No
Content>
[DEBUG @google 00:03:19] starting PROPFIND
[DEBUG @google 00:03:19] PROPFIND: Neon error code 1: 404 Not Found, must not
retry
[DEBUG @google 00:03:19] @google/calendar: exception thrown at
/home/pohly/syncevolution/syncevolution/src/backends/webdav/NeonCXX.cpp:649
[ERROR @google 00:03:19] @google/calendar: error code from SyncEvolution object
not found (remote, status 404): PROPFIND: Neon error code 1: 404 Not Found
This is a temporary error, trying again (as in a --print-items command line
operation) shows the event:
UNIQUE-UID-1308257075-030-UNIQUE-UID-1308257075-1234567890%40dummy%2eics:
030-phone meeting, 030-my office
The retry mechanism should be triggered in those cases where we are pretty sure
that 404 must be incorrect.
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: normal
Priority: Undecided
Keywords:
Status: NEW
Who: patrick.ohly(a)intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=19433
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 7 months
[Bug 14891] New: [pretest] Mobical.net is changed to everdroid.com
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=14891
Summary: [pretest] Mobical.net is changed to everdroid.com
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: major
Priority: High
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
Created an attachment (id=5109)
--> (https://bugs.meego.com/attachment.cgi?id=5109)
everdroid service
BUILD IMAGE: BUILD IMAGE:: meego-netbook-ia32-1.1.90.8.20110323.1
HARDWARE MODEL (on what HW this bug is uncovered): netbook
BUG DETAILED DESCRIPTIONS
===========================================================
We failed to do two-way sync with mobical. Then, log on to its website, find
the www.mobical.net is automatically redirected to www.everdroid.com (please
see attachment).
Developer, please confirm that change. If so, we need to know: will we support
mobical in the future? High priority to get answer. Thanks!
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 7 months
[Bug 19488] New: local configurations should always be 'present'
by bugzilla＠meego.com
https://bugs.meego.com/show_bug.cgi?id=19488
Summary: local configurations should always be 'present'
Classification: MeeGo Projects
Product: SyncEvolution
Platform: ---
Version: unspecified
Platform: Common
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jku(a)linux.intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
Local configs currently always have "No transport" presence. The right (or at
least better) value would be to always return "" (as in MIGHTWORK).
--------
Product: SyncEvolution
Component: SyncEvolution
MeeGo Release: unspecified
Severity: normal
Priority: Undecided
Keywords:
Status: NEW
Who: jku(a)linux.intel.com
Assigned To: syncevolution-bugs(a)meego.bugs
Target Build: ---
Flags:
Changed:
--------
https://bugs.meego.com/show_bug.cgi?id=19488
--
Configure bugmail: https://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8 years, 7 months