[Bug 8177] New: Add support for handling http proxy set in env
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=8177
Summary: Add support for handling http proxy set in env
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Generic
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: *Feature Request
AssignedTo: rajyalakshmi.bommaraju(a)intel.com
ReportedBy: rajyalakshmi.bommaraju(a)intel.com
CC: syncevolution(a)lists.intel.com
http_proxy env variable is handled transparently by the transport
library - except that only libcurl honors it whereas libsoup ignores it
in. I'm not sure what the rationale for that is.
If available, then we use libsoup-gnome, which gets proxy settings
automatically from the central GNOME settings. This is how it works in
Moblin.
It certainly would be nice to have support for http_proxy as in many
other apps. Should we add support for it on top of libsoup/libcurl? In
SyncConfig::getUseProxy(), return TRUE if http_proxy is set and
non-empty, FALSE if it is set and empty, otherwise return the configured
value. In SyncConfig::getProxyHost(), return the value of http_proxy if
set, otherwise the configured value.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12 years, 6 months
[Bug 9329] New: Manually added sources will affect new configuration unexpectly
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=9329
Summary: Manually added sources will affect new configuration
unexpectly
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: yanshuang.zheng(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution(a)lists.intel.com
pkg: sync-0.9.99.4
As bug #8424 described, sync will create a new source if user needs it for
configured service. Thus, the new added source should only be in the very
configured service. But with sync-0.9.99.3(or 4), the behavior is: After this
new source is added to service A, it will also be added to all services that
change/create configuration. It collects a union set of sources in all service.
Steps:
1. setup configurations with scheduleoworld template:
$syncevolution -c -y username=<my_account> -y password=<my_password> -l
scheduleworld test1
$syncevolution -c -y username=<my_account> -y password=<my_password> -l
scheduleworld test2
2. add a new source to test1:
$syncevolution -c -z uri=xxx test1 xxx
==> new source 'xxx' in test1, no 'xxx' in test2
3. change configuration of test2:
$syncevolution -c -s two-way test2
==> new source 'xxx' in test2
4. add a new configuration test3:
$syncevolution -c -y username=<my_account> -y password=<my_password> -l
scheduleworld test3
==> there is 'xxx' in test3
Assume it a regression brought by fixing bug #8424
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12 years, 6 months
[Bug 8879] New: missing bluetooth adapter not noticed when syncing
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=8879
Summary: missing bluetooth adapter not noticed when syncing
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: minor
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: jku(a)linux.intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: syncevolution(a)lists.intel.com
My laptop Bluetooth was somehow disabled when I tried to sync. The result was
500 with
[ERROR] TransportException while sending SAN package
[ERROR] Server Alerted Sync init failed
There should be a check for an existing local bluetooth adapter and a
corresponding error.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12 years, 6 months
[Bug 8758] New: should not resend on some http errors
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=8758
Summary: should not resend on some http errors
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: jku(a)linux.intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: syncevolution(a)lists.intel.com
I was trying to break syncevolution and the UI with interesting configs...
Setting syncURL to a http server that is not a syncml server gives a 405
response. Syncevolution then proceeds with the resend cycle. This seems
unnecessary and makes the user experience pretty bad: it takes 5 minutes to
find out that there's something wrong with the URL.
I should maybe file a new bug for this but maybe this is related: I get 20043
(LOCERR_TRANSPFAIL) as the eventual error for the above. That is the exact same
thing I get for failed name resolution (syncURL="http://invalid.invalid") and a
bad url (syncURL="a"). Being able to tell those apart would be great.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12 years, 6 months
[Bug 8496] New: SAN generation: always use "base" type (text/x-vcard, text/x-vcalendar)
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=8496
Summary: SAN generation: always use "base" type (text/x-vcard,
text/x-vcalendar)
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: Undecided
Component: *Feature Request
AssignedTo: congwu.chen(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Congwu, did you see this discussion on the Synthesis mailing list?
--------------------------------------------------------------
From: Lukas Zeller <luz(a)synthesis.ch>
To: Ohly, Patrick <patrick.ohly(a)intel.com>
Cc: Chen, Congwu <congwu.chen(a)intel.com>, os-libsynthesis(a)synthesis.ch
<os-libsynthesis(a)synthesis.ch>
Subject: Re: [os-libsynthesis] More calendar tests problems
Date: 12/02/2009 05:05:56 PM (Wed, 2 Dec 2009 16:05:56 +0000)
Hi Patrick,
On Dec 2, 2009, at 16:08 , Patrick Ohly wrote:
>> I doubt (but haven't tried to prove) that the MIME type in the SAN
>> would really influence type negotiation, I'd assume it is used as a
>> safer identifier for the store than the name is, but as long as you
>> use a mime type that is valid for that datastore I'd expect it would
>> trigger a sync in the same way as a manual start would.
>
> So you are proposing to always use "text/x-vcalendar" (or its binary
> equivalent) even if we would prefer "text/calendar"? That might work,
> except for those hypothetical handsets which *only* support
> "text/calendar".
Yes :-)
--------------------------------------------------------------
Is this something that we should implement?
We could build the logic so that unless "type" forces a specific type
(exclamation mark), we always use the older format. That applies to both
contacts (text/x-vcard) as well as events (text/x-vcalendar).
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12 years, 6 months
[Bug 8092] New: smaller log files
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=8092
Summary: smaller log files
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: P2
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Our nightly testing at log level 4 produces 3GB of data each night. At first
glance it seems that .html logs comprise most of the data, and in turn often
because of the dump of our XML config.
Let's see whether we can get the size of the logs down a bit:
- log the XML config only at loglevel 5
- check for useless chatter in the log and remove it
--
Configure bugmail: http://bugzilla.moblin.org/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.
12 years, 6 months
[Bug 7710] New: server session handling
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7710
Summary: server session handling
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: P1
Component: *Feature Request
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Depends on: 7707
In server mode, we have the following problems:
- sessions that the client no longer replies to don't time out,
blocking new sync sessions
- a client aborting one session and starting a new one is not
able to do so until the previous session has timed out; it
would be nicer if the server would detect this and close the
older session
- we should delay picking a peer configuration until we really
know the peer's device ID; currently we only check that the
pre-chosen peer configuration matches
- database dumping should be delayed until we know a) that the
client is authorized and b) which sources are really active
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12 years, 6 months
[Bug 7708] New: improved database dump handling
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7708
Summary: improved database dump handling
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: P1
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Depends on: 7707
The current approach of dumping each active data source at the start and end of
a sync run has several problems:
- inefficient use of disk space because full dumps are kept
even if nothing has changed
- inactive sources are not dumped; when enabled again the next time,
the compare feature only looks into the latest log dir for the
current peer, doesn't find a dump of the source there and thus
doesn't compare.
The first problem becomes critical on devices with small amount of free space
*and* when doing frequent automatic syncs (bug #6378). The later one is
annoying.
I suggest the following solution:
- Do dumps exactly as they are done now, with one file per item.
- In a post-processing step, identify item files which have the
same *content* (not necessarily the same name!) as in the last
dump and replace those with hard links to the older file.
- Provide utility code which finds a previous database dump.
It should ignore the peer that the data was dumped for, which
depends on the revised config handling. Use that utility code
in status checks.
The advantage of this solution is that synccompare and shell access to log dirs
and database dumps works unchanged. I also considered going one step further
and storing all dumps in a database or in git (which would give us compression
in addition to detection of identical files), but that is a lot more
complicated and prevents easy access to the data.
The current code is in the LogDir class. This is getting ugly, so perhaps a
major code restructuring is due.
--
Configure bugmail: http://bugzilla.moblin.org/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.
12 years, 6 months
[Bug 6376] New: sync-ui + D-Bus server: implement interactive password requests
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=6376
Summary: sync-ui + D-Bus server: implement interactive password
requests
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: P2
Component: * Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Release Milestone: Undecided
We have defined the API (Server.InfoRequest/Response), but it is currently not
in the syncevo-dbus-server. Next steps:
1. add to interface with stubs
2. implement it in D-Bus server
3. implement it in GUI
--
Configure bugmail: http://bugzilla.moblin.org/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.
12 years, 6 months
[Bug 7089] New: pairing with Bluetooth devices
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=7089
Summary: pairing with Bluetooth devices
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: P1
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: josh(a)linux.intel.com, syncevolution(a)lists.intel.com
Release Milestone: Undecided
When pairing a Moblin (or Linux) instance with another Bluetooth device we want
to enable SyncML, or at least have the option to do so. The exact steps
necessary for this are uncertain at this time. Joshua Lock is working on the
GUI integration in Moblin and answered about having seen anything SyncML
related:
---------------------------------------------------------
Nope, but I have seen that the plugin API is incredibly simple:
http://git.gnome.org/cgit/gnome-bluetooth/tree/lib/bluetooth-plugin.h
The only downside is that is assumes you want to provide some sort of
configuration UI for users to choose to enable plugins, whereas in
Moblin we'll probably just want to automatically enable them with sane
defaults.
A general syncevolution plugin with a checkbox to enable this device as
a sync target doesn't look like it would be too hard, the geoclue one is
less than 300LOC:
http://git.gnome.org/cgit/gnome-bluetooth/tree/lib/plugins/geoclue.c
---------------------------------------------------------
--
Configure bugmail: http://bugzilla.moblin.org/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.
12 years, 6 months