Re: [Evolution-hackers] Evolution Exchange in Ubuntu Hardy

2008-04-08 Thread George Farris
On Mon, 2008-04-07 at 21:43 -0400, Michael B. Trausch wrote:
 On Mon, 2008-04-07 at 21:14 -0400, Paul Smith wrote:
  Unless something radical happens in the next few weeks to resolve
  all these problems, I regret to say that this Ubuntu Long-Term
  Support release will not be anywhere close to ready to deploy in an
  enterprise environment.

I completely agree.  I know of myself and at least two others running
Hardy with Evolution Exchange backend and it is unusable because the
exchange backend keeps dying.



___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution Exchange in Ubuntu Hardy

2008-04-08 Thread Paul Smith
On Tue, 2008-04-08 at 08:08 -0700, George Farris wrote:
 I completely agree.  I know of myself and at least two others running
 Hardy with Evolution Exchange backend and it is unusable because the
 exchange backend keeps dying.

Are you on 32bit or 64bit systems?  Do you have multiple CPUs?

It really confuses me, because as I said I've been using my makefile
( http://mad-scientist.us/evolution.html ) to build from SVN on my Gutsy
system, and it runs _great_.

I can't figure out what's different about Hardy that's causing this
problem.

-- 
-
 Paul D. Smith [EMAIL PROTECTED] http://make.mad-scientist.us
 Please remain calm--I may be mad, but I am a professional.--Mad Scientist


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] detecting new ical memory tracking

2008-04-08 Thread Patrick Ohly
Hello,

I now have the situation that I feared in issue #516408: SyncEvolution
trunk uses libical calls where the returned string must be freed when
SyncEvolution runs with Evolution 2.22 and must not be freed when run
with older Evolution releases. My plan still is to only provide only one
binary for 2.10, 2.12, 2.22, therefore I need the runtime detection of
the API change that I suggested in
http://bugzilla.gnome.org/show_bug.cgi?id=516408#c31

Introducing the code rewrite suggested by Michael is impossible. Can I
have the less intrusive patch included on trunk and the stable branch,
please? Or is there some other version number which can be queried at
runtime? I'd rather not parse /proc/self/maps to find out what the
revision of libecal is... As discussed in #516408, checking the version
number would be sub-optimal.

FWIW, the leak shows up nicely in the nightly testing:
http://www.estamos.de/runtests/2008-04-08-10-00/head-evolution-trunk-minimal/6-evolution/

-- 
Bye, Patrick Ohly
--  
[EMAIL PROTECTED]
http://www.estamos.de/

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] detecting new ical memory tracking

2008-04-08 Thread Matthew Barnes
On Tue, 2008-04-08 at 21:42 +0200, Patrick Ohly wrote:
 Introducing the code rewrite suggested by Michael is impossible. Can I
 have the less intrusive patch included on trunk and the stable branch,
 please? Or is there some other version number which can be queried at
 runtime? I'd rather not parse /proc/self/maps to find out what the
 revision of libecal is... As discussed in #516408, checking the version
 number would be sub-optimal.

More broadly, we should add some versioning macros and symbols to
libedataserver similar to [1], so Patrick could do something like:

#if EDS_CHECK_VERSION(2,22,0)
... free libical strings ...
#endif

Would that address your needs, Patrick?

Matthew Barnes


[1]
http://library.gnome.org/devel/glib/unstable/glib-Version-Information.html

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-08 Thread Patrick Ohly
On Mo, 2008-04-07 at 23:40 -0600, P Chenthill wrote:
 On Thu, 2008-04-03 at 19:45 +0200, Patrick Ohly wrote:
  One could argue that the sending program is at fault: it could have used
  a different TZID after changing the timezone definition. Alternatively
  it could have sent a more complex VTIMEZONE which also includes the
  historic rules. I believe both causes other problems in practice.
  Speculating about it is futile anyway and won't change the meeting
  invitations that Evolution has to deal with.
  
  Besides, don't blame Outlook too much: Evolution = 1.12 now does
  exactly the same thing. For example, a meeting invitation now uses
  /softwarestudio.org/Tzfile/America/Los_Angeles and only includes the
  current rules for daylight saving transitions.
 It just includes the current rules for outlook compatibility.

Yep, that's the I believe both causes other problems in practice
part ;-)

 I am just back after a small vacation.

Ah, that explains the silence. I'll be away over the weekend and Monday
myself and don't know whether I'll have time before I came back.

 I dont think anyone is work on this issue currently. I made a patch for
 exchange backend for solving this issue long time back. But
 unfortunately its not committed in trunk.

Why? Technical issues that I should be aware of?

  It uses a timestamp in the
 VTIMEZONE file to store the latest one always. By this way we would also
 know the last time period when the timezone has been changed for that
 location.

I can't claim to understand the patch or the code that it applies to.
When you say that only the latest VTIMEZONE is stored, that implies that
only one is stored, right? How does that solve the problem of having an
event in the calendar which depends on an old revision of the VTIMEZONE
and another one which needs the current revision?

 I am ok with handling using the sequence numbers. I am not sure whether
 a new libecal API would be needed to solve this, since the timezones
 would be handled at the backend.

The client adds the VTIMEZONE and some time later the corresponding
event. At that time the backend won't be able to correlate the two, but
that is necessary to change the TZID in the event if the VTIMEZONE was
stored with a different TZID. Only the client can do that.

 It would be better to handle all the timezones in a common place inside
 EDS. The reason for that is, same timezones can exist in multiple
 calendars which could not be matched to either system timezone or
 through the fuzzy logic. Currently it is handled separately for every
 calendar and the same information is stored redundantly. Another issue
 which should be taken care of is, the system timezones should not be
 stored in the cache. They should always be taken from the libical
 builtin timezone. Please consider these too while implementing the
 solution.

That's way beyond what I have time for, sorry. Besides, I want to keep
my changes as small as possible to increase the chance of getting them
into the stable branch.

-- 
Bye, Patrick Ohly
--  
[EMAIL PROTECTED]
http://www.estamos.de/

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] detecting new ical memory tracking

2008-04-08 Thread Patrick Ohly
On Di, 2008-04-08 at 18:29 -0400, Matthew Barnes wrote:
 More broadly, we should add some versioning macros and symbols to
 libedataserver similar to [1], so Patrick could do something like:
 
 #if EDS_CHECK_VERSION(2,22,0)
 ... free libical strings ...
 #endif
 
 Would that address your needs, Patrick?

It probably would work in practice, but I would have to make assumptions
about which versions contain this new feature. As Chris Lord pointed
out, eds-dbus might pick up the patch and then offer it under a
different version. As of last weekend, SyncEvolution can synchronize
calendars on Maemo with EDS-DBus, so I care about that. Making it work
with that were part of the reason for changing SyncEvolution.

Even if you add versioning information to 2.22.x, I still would have to
depend on dlsym() tricks to work with older releases.

-- 
Bye, Patrick Ohly
--  
[EMAIL PROTECTED]
http://www.estamos.de/

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution Exchange in Ubuntu Hardy

2008-04-08 Thread Paul Smith
On Tue, 2008-04-08 at 13:15 -0400, Paul Smith wrote:
 I can't figure out what's different about Hardy that's causing this
 problem.

There was a major update to Hardy today that included all parts of
Evolution, including e-d-s and evolution-exchange.  The bugs listed
there looked very serious: freeing null pointers and other really
unpleasant things.  There haven't been any changes to the gnome-2-22
branch in SVN for anything like this in quite a while, so I'm not sure
where these fixes came from (or maybe more accurately, where the
previous, unfixed versions came from).

After the upgrade my Evo in Hardy was stable and responsive for an hour
or two before I had to come home (but, now my system doesn't recognize
the proper screen size for my LCD monitor... but that's another story).

I'm not ready to call it fixed quite yet, but if you haven't updated
lately you should do so, then see if things are any better for you.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.us
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution Exchange in Ubuntu Hardy

2008-04-08 Thread HggdH
On Tue, 2008-04-08 at 20:54 -0400, Paul Smith wrote:
 There was a major update to Hardy today that included all parts of
 Evolution, including e-d-s and evolution-exchange.  The bugs listed
 there looked very serious: freeing null pointers and other really
 unpleasant things.  There haven't been any changes to the gnome-2-22
 branch in SVN for anything like this in quite a while, so I'm not sure
 where these fixes came from (or maybe more accurately, where the
 previous, unfixed versions came from).

The fixes came from upstream indeed. They are fixes that were committed
from about March 10th to April 7th (i.e., from the 2.22.00 release to
2.22.1). Additionally, the Ubuntu 2.22.1 change logs ([1], [2], and [3])
list the bugzilla fixes included on 2.22.1.

The Ubuntu/Debian specific fixes are listed in the source packages,
under ./debian/patches; a quick look there did not show me anything we
added off upstream that would address the memory corruption, etc.

 I'm not ready to call it fixed quite yet, but if you haven't updated
 lately you should do so, then see if things are any better for you.

Anyway, of course, for Ubuntu we do recommend you run the up-to-date
versions -- remember we are still beta on Hardy 8.04.

I have been busy lately but, to my (dim) remembering, the only critical
issue we still have left on Evo for Hardy is the E-D-S loop on startup
([4] for Ubuntu, [5] for bugzilla).

Regards,

..hggdh..

[1]
https://lists.ubuntu.com/archives/hardy-changes/2008-April/010564.html
[2]
https://lists.ubuntu.com/archives/hardy-changes/2008-April/010569.html
[3]
https://lists.ubuntu.com/archives/hardy-changes/2008-April/010588.html
[4]
https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/151536
[5] http://bugzilla.gnome.org/show_bug.cgi?id=518524



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution Exchange in Ubuntu Hardy

2008-04-08 Thread Paul Smith
On Wed, 2008-04-09 at 04:03 +0200, HggdH wrote:
 The fixes came from upstream indeed. They are fixes that were
 committed from about March 10th to April 7th (i.e., from the 2.22.00
 release to 2.22.1).

OK, gotcha.  I incorrectly assumed that 2.22.1 was already in Hardy.
I'll give it a good workout tomorrow and make sure it's stable.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.us
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Building Evo SVN on Ubuntu Hardy

2008-04-08 Thread HggdH
Hello,

I used Paul Smith's Makefile ([1]) to build Evolution on Ubuntu Hardy
(by the way, the easiest way to build evo from SVN I have seen so
far...).

The original Makefile does not address Hardy (stops at Gutsy), so I made
a quick patch for it. I did not stop to check the prereqs, but Gutsy
prereqs seem to work on Hardy; there may be others, but my system is
already set to development, and might already have them. YMMV.

If you are interested, I have attached the patch here. 

Thanks to Paul for setting this up in the first place.

..hggdh..

[1] http://mad-scientist.us/evolution.html

--- Makefile.orig	2008-02-28 04:52:49.0 +0100
+++ Makefile	2008-04-09 04:44:46.0 +0200
@@ -64,7 +64,7 @@
 # successful build are installed.  The currently supported distros are
 # listed in the DISTROS variable below.
 # If yours is not one of these, set this to empty and take your chances!
-DISTRO :=	gutsy
+DISTRO :=	hardy
 
 # Comment this out if you don't want to use ccache
 CCACHE :=	ccache
@@ -92,7 +92,7 @@
 # These are the prerequisite packages needed on the system before we can build
 # Evo.  There are different ways to check for them, based on distro.
 
-DISTROS :=	feisty gutsy etch
+DISTROS :=	feisty gutsy hardy etch
 
 feisty-PREREQS := \
 		gtk-doc-tools subversion flex bison build-essential \
@@ -105,6 +105,12 @@
 		libgail-dev evolution-dev icon-naming-utils libdbus-glib-1-dev \
 		$(CCACHE)
 
+hardy-PREREQS := \
+		gtk-doc-tools subversion flex bison build-essential \
+		libssl-dev libldap2-dev libnss3-dev libnspr4-dev \
+		libgail-dev evolution-dev icon-naming-utils libdbus-glib-1-dev \
+		$(CCACHE)
+
 etch-PREREQS := \
 		gtk-doc-tools subversion flex bison build-essential \
 		libssl-dev libldap2-dev libnss3-dev libnspr4-dev \
@@ -461,7 +467,7 @@
 	 $(ECHO) Or to force a build, set 'distro' empty in the makefile.; \
 	 exit 1
 
-check-prereqs-gutsy check-prereqs-feisty check-prereqs-etch: check-prereqs-%:
+check-prereqs-hardy check-prereqs-gutsy check-prereqs-feisty check-prereqs-etch: check-prereqs-%:
 	@log=/tmp/evo-chk-prereqs. \
 	   $(RM) $$log \
 	   $(TOUCH) $$log \



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers