5:20 a.m.
Hello!
For those of you running the 0.9.1 beta announced last week, please
update to beta 2. The bug hunt is still on, so please test and provide
feedback...
SyncEvolution 0.9.1 beta 1 -> 0.9.1 beta 2, 19.10.2009
======================================================
Several fixes:
* Receiving photos from Mobical failed because Mobical does not
quite follow the vCard 2.1 (Moblin Bugzilla #6668). Sending
photos worked, but added a few bytes of garbage at the end of
each photo (typically ignored when showing). Parser was made
more tolerant by Synthesis and encoder bug was fixed.
* Task priorities used by Mobical and Evolution did not match:
vCalendar 1.0 uses 1-3, iCalendar 2.0 uses 1-9 (MB #6664).
SyncEvolution now translates between the two ranges, with some
information getting lost when talking to a peer which only
supports the smaller range.
* The workaround for detecting an endless stream of Alert 222
messages (caused by misbehavior of certain servers when a
specific message has to be resent) aborted certain valid (albeit
somewhat pathologic) sync sessions. Improved the heuristic so
that it still catches the real loop without aborting in that
other case.
* sync-ui: now disables sources which are not supported when
setting up a configuration, like memos on Moblin (MB #6672).
Previously the source was enabled, which prevented using using
the configuration as-is on the command line.
* .rpms on syncevolution.org no longer specify a dependency on
certain Perl features. This depencency was a problem on
Mandriva. Unwanted hard dependencies on libecal in
syncevolution.org binaries are avoided for real this time
(MB#6552).
* Trying to remove a non-existent configuration via the command
line now raises an error, to catch typos (MB #6673).
* Message resend options: added sanity checks to catch negative
values, clarified that duration is given in seconds, 0s resend
interval disables resending (MB #6500).
* Spelling fix: "aboring" => "aborting"
Source, Installation, Further information
=========================================
http://syncevolution.org/blogs/pohly/2009/syncevolution-091-beta-released
Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources
Binaries for Debian-based distributions are available via the "unstable"
syncevolution.org repository. Add the following entry to
your /apt/source.list, then install "syncevolution-evolution":
deb http://downloads.syncevolution.org/apt unstable main
These binaries include the new "sync-ui" GTK GUI and were compiled for
Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can
no longer be supported with precompiled binaries because of missing
libraries, but the source still compiles when not enabling the GUI (the
default).
The same binaries are also available as .tar.gz and .rpm archives in
http://downloads.syncevolution.org/syncevolution/evolution. In contrast
to 0.8.x archives, the 0.9 .tar.gz archives have to be unpacked and the
content must be moved to /usr, because several files would not be found
otherwise.
After installation, follow the getting started steps:
http://syncevolution.org/documentation/getting-started
--
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.
6:01 a.m.
Hi Patrick,
On Tue, Oct 20, 2009 at 1:20 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
Hello!
For those of you running the 0.9.1 beta announced last week, please
update to beta 2. The bug hunt is still on, so please test and provide
feedback...
I'm having issues building this on Fedora 12. The error looks like it
should be able to install into a build root environment but it seems
there's an issue with the check. I had the same issue with beta1 but
0.9.0 builds fine.
make[4]: Nothing to be done for `install-exec-am'.
test -z "/usr/lib64/syncevolution/backends/" || /bin/mkdir -p
"/home/perobinson/rpmbuild/BUILDROOT/syncevolution-0.9+0.9.1beta2-1.fc12.x86_64/usr/lib64/syncevolution/backends/"
/bin/sh ../../../libtool --mode=install /usr/bin/install -c
syncecal.la syncebook.la
'/home/perobinson/rpmbuild/BUILDROOT/syncevolution-0.9+0.9.1beta2-1.fc12.x86_64/usr/lib64/syncevolution/backends/'
libtool: install: error: cannot install `syncecal.la' to a directory
not ending in /usr/lib64/syncevolution/backends/
make[4]: *** [install-backendLTLIBRARIES] Error 1
Cheers,
Peter
7:31 a.m.
On Tue, 2009-10-20 at 14:01 +0100, Peter Robinson wrote:
Hi Patrick,
On Tue, Oct 20, 2009 at 1:20 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> Hello!
>
> For those of you running the 0.9.1 beta announced last week, please
> update to beta 2. The bug hunt is still on, so please test and provide
> feedback...
I'm having issues building this on Fedora 12. The error looks like it
should be able to install into a build root environment but it seems
there's an issue with the check. I had the same issue with beta1 but
0.9.0 builds fine.
We changed the way how the backends are installed:
commit 35ee63661949243bfb4bc00afd33b5d68489975d
Author: Chen Congwu <congwu.chen(a)intel.com>
Date: Wed Sep 2 11:13:10 2009 +0800
Dynamic loadable backends: repackage libsyncevolution to enable dynamic loadable
backends
Install head files to a standard path, the remaining dependencies are
synthesis and boost
client-test is portable when ENABLE_MODULES is defined, no longer link to
backends libraries.
Add --enable-developer-mode, in which mode the backend scan path will be
under current build directory for development purposes.
...
diff --git a/src/backends/evolution/Makefile.am b/src/backends/evolution/Makefile.am
index 997349c..23bf672 100644
--- a/src/backends/evolution/Makefile.am
+++ b/src/backends/evolution/Makefile.am
@@ -1,11 +1,11 @@
...
if ENABLE_MODULES
-pkglib_LTLIBRARIES = $(SYNCSOURCES)
+backend_LTLIBRARIES = $(SYNCSOURCES)
Congwu, do you remember why backend_ instead of pkglib_ is better? Any
idea for solving this issue on Fedora 12?
Peter, does the problem perhaps go away when running "./autogen.sh" in
the SyncEvolution source directory and then reconfiguring/recompiling?
Which version of libtool do you have on Fedora 12? Finally, do the .rpms
provided on syncevolution.org work on Fedora 12?
I definitely want to solve this problem, but it is equally important to
know whether providing the .rpms is worthwhile.
--
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.
7:17 p.m.
Patrick Ohly wrote:
Congwu, do you remember why backend_ instead of pkglib_ is better?
Any
idea for solving this issue on Fedora 12?
I want to install the backend libraries into $pkglibdir/backends.
$backenddir is set during config: $backendir = $libdir/syncevolution/backends
Looks like $backenddir is not set correctly to add the BUILDROOT prefix.
I am not familiar with rpm build but in our test machine, we are using:
./configure && ./make && ./make install DESTDIR=xxx
Quite the same process as the rpm build.
Best Regards,
Congwu
3:31 a.m.
Hi Patrick,
Sorry for the delay in response, it slipped through the cracks.
> > For those of you running the 0.9.1 beta announced last week,
please
> > update to beta 2. The bug hunt is still on, so please test and provide
> > feedback...
>
> I'm having issues building this on Fedora 12. The error looks like it
> should be able to install into a build root environment but it seems
> there's an issue with the check. I had the same issue with beta1 but
> 0.9.0 builds fine.
We changed the way how the backends are in
<snip>
Congwu, do you remember why backend_ instead of pkglib_ is better?
Any
idea for solving this issue on Fedora 12?
The problem still exists in the final 0.9.1 release.
Peter, does the problem perhaps go away when running
"./autogen.sh" in
the SyncEvolution source directory and then reconfiguring/recompiling?
Which version of libtool do you have on Fedora 12? Finally, do the .rpms
provided on syncevolution.org work on Fedora 12?
I've not tested the rpms on syncevolution.org and ultimately doing so
won't fix the problem I need to deal with. Running ./autogen.sh fails
because it in turn trys to run "sh ./gen-autotools.sh" which doesn't
exist in the release but running autoreconf makes no difference so I
suspect it won't change anything.
I definitely want to solve this problem, but it is equally important
to
know whether providing the .rpms is worthwhile.
For Fedora, probably not as people will use the ones in the main
distro. Most people don't want to have to go to multiple sites to get
updates and new releases but rather just want the package manager to
deal with it.
Regards,
Peter
4:34 a.m.
On Thu, 2009-11-05 at 11:31 +0000, Peter Robinson wrote:
> Congwu, do you remember why backend_ instead of pkglib_ is
better? Any
> idea for solving this issue on Fedora 12?
The problem still exists in the final 0.9.1 release.
Yes, we haven't done anything about it. The autotools usage looks right
to me, so I'm a bit at a loss how to solve it.
> Peter, does the problem perhaps go away when running
"./autogen.sh" in
> the SyncEvolution source directory and then reconfiguring/recompiling?
> Which version of libtool do you have on Fedora 12? Finally, do the .rpms
> provided on syncevolution.org work on Fedora 12?
I've not tested the rpms on syncevolution.org and ultimately doing so
won't fix the problem I need to deal with. Running ./autogen.sh fails
because it in turn trys to run "sh ./gen-autotools.sh" which doesn't
exist in the release
That's something that we should fix =>
http://bugzilla.moblin.org/show_bug.cgi?id=7822
but running autoreconf makes no difference so I
suspect it won't change anything.
Did that recreate libtool with the version from FC12?
The version of ltmain.sh bundled with the source is
"1.5.26 Debian 1.5.26-1ubuntu1".
To run ./autogen.sh, you could download the missing gen-autotools.sh
here:
http://git.moblin.org/cgit.cgi/syncevolution/plain/gen-autotools.sh?h=syn...
> I definitely want to solve this problem, but it is equally
important to
> know whether providing the .rpms is worthwhile.
For Fedora, probably not as people will use the ones in the main
distro. Most people don't want to have to go to multiple sites to get
updates and new releases but rather just want the package manager to
deal with it.
That's of course the right approach for people who prefer their distro's
packages. But for people who want the latest stable (or unstable)
release in a distro that is in maintenance mode, the only alternatives
are installing from source or using our binary packages.
--
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.
4010
days inactive
4026
days old
syncevolution@synevolution.org
5 comments
3 participants
participants (3)
-
Chen, Congwu -
Patrick Ohly -
Peter Robinson