[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evolution
Subject:    [Evolution] Re: evolution sync problem with newest pilot-link
From:       "Jason 'vanRijn' Kasper" <vR () movingparts ! net>
Date:       2002-07-06 21:08:34
Message-ID: 1025989714.15648.4.camel () tobias
[Download RAW message or body]

On Sat, 2002-07-06 at 14:44, Ben Darnell wrote:
> On Sat, Jul 06, 2002 at 02:21:20PM -0400, Jason 'vanRijn' Kasper wrote:
> > The version of pilot-link that gpilotd is compiled against is 0.9.5,
> > while the pilot-link version on my system is 0.10.99.  Any ideas as to a
> > cause or a solution, or even a "hey, weird, I'm seeing that too"?
> 
> I don't use gnome, but I am the maintainer of the debian pilot-link
> packages and can explain what has happened with the 0.10.99 upgrade.  If
> gpilotd only uses the libpisock library, it should be fine - libpisock4
> (0.9.5) and libpisock5 (0.10.99) can both be installed at the same time,
> and gpilotd will continue using libpisock4 until it is recompiled
> against libpisock5.  
> 
> If, on the other hand, evolution uses any of the pilot-link executables
> (such as read-ical or install-datebook), it's possible that it may be
> falling victim to changes in command-line parameters in those utilities.  
> 

Just to follow up....  I've fixed this annoying problem on my box.  I've
recompiled both evolution and gnome-pilot by hand, against libpisock5. 
I don't know whether evolution uses the pilot-link executables as Ben
was saying above (can anyone speak to that?).  

I did try to recompile just evolution against 0.10.99, but that didn't
fix the problem (it may already have been compiled against libpisock5?),
but after recompiling gnome-pilot against 0.10.99, I'm able to actually
read the things in my calendar again (nice little feature, that).

Anyone else have problems with this combination?



-- 

,-----------------------------------------------------------------//
| Jason 'vanRijn' Kasper ::  Numbers 6:22-26 
 `
 | All brontosauruses are thin at one end, much MUCH thicker 
 | in the middle, and then thin again at the far end.  That is 
 | the theory that I have and which is mine, and what it is too.  
 ,
| bash$ :(){ :|:&};:
`----------------------//


[prev in list] [next in list] [prev in thread] [next in thread]