Hello sogo users,
I have a problem with recurring events.
If I create a recurring event on Outlook 2010, Sogo correctly save the data
on the database.
When I create an exception (I edit an instance of a recurring event), I see
the exception on the client, but after folder update, the exception
di
En/na Luca Olivetti ha escrit:
Well, I managed to compile sogo with "-fno-stack-protector" and the
problem went away.
Of course I'm quite scared to deploy it: it could be that
objective-c/gnustep/sogo doesn't play well with -fstack-protector (but
notice that everything else but sogo has been
En/na Luca Olivetti ha escrit:
Al 18/09/10 14:28, En/na Luca Olivetti ha escrit:
I now tried to initialize ranges with
ranges = [[NSMutableArray alloc] initWithCapacity: numberOfMonthsInRange]
instead of
ranges = [NSMutableArray] arrayWithCapacity: numberOfMonthsInRange]
that gets rid of t
Al 18/09/10 14:28, En/na Luca Olivetti ha escrit:
I now tried to initialize ranges with
ranges = [[NSMutableArray alloc] initWithCapacity: numberOfMonthsInRange]
instead of
ranges = [NSMutableArray] arrayWithCapacity: numberOfMonthsInRange]
that gets rid of the 4294967295 issue, but it stil
Al 18/09/10 11:55, En/na Luca Olivetti ha escrit:
Al 17/09/10 22:10, En/na Luca Olivetti ha escrit:
Al 17/09/10 17:37, En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
Since I still have the RPMs built under mandriva 2009.1, I replaced
everything w
Al 17/09/10 22:10, En/na Luca Olivetti ha escrit:
Al 17/09/10 17:37, En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
Since I still have the RPMs built under mandriva 2009.1, I replaced
everything with the old versions (gnustep-base included) and th
Al 17/09/10 17:37, En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
Since I still have the RPMs built under mandriva 2009.1, I replaced
everything with the old versions (gnustep-base included) and the stack
smashing is still there, so it's either ano
En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
Since I still have the RPMs built under mandriva 2009.1, I replaced
everything with the old versions (gnustep-base included) and the stack
smashing is still there, so it's either another library causing it (it
happens in libc) or an
En/na Luca Olivetti ha escrit:
Since I still have the RPMs built under mandriva 2009.1, I replaced
everything with the old versions (gnustep-base included) and the stack
smashing is still there, so it's either another library causing it (it
happens in libc) or an underlying problem in sope/sogo.
En/na Luca Olivetti ha escrit:
The "funny" (not really) thing is that the stack smashing is back :-(
I upgraded the test server with the same version of the distribution as the
production server.
The test server previously was mandriva 2009.1:
gcc-3.4.2
gnustep-base-1.18.0
gnustep-make-2.0.8
On Lunes 30 Agosto 2010 16.11 CEST, Luca Olivetti wrote:
>
> Been away from sogo for a while. Now I'm testing 1.3.1.
Still working on this on and off :-(
> I took a backup with sogo-tool and restored it in a test server with
> 1.3.1 (using -F to use the same data).
>
> There's no problem wit
En/na Ludovic Marcotte ha escrit:
On 31/08/10 11:39 AM, Luca Olivetti wrote:
Probably, in fact he's using a windows mobile device :-/ but I doubt
he's the only one.
But, shouldn't the funambol connector filter/massage those entries,
For massaging, we generally point folks to http://sogo.ca/
On 31/08/10 11:39 AM, Luca Olivetti wrote:
Probably, in fact he's using a windows mobile device :-/ but I doubt
he's the only one.
But, shouldn't the funambol connector filter/massage those entries,
For massaging, we generally point folks to http://sogo.ca/
avoiding them entering the database
En/na Wolfgang Sourdeau ha escrit:
Does anybody know how that (wrong?) data could possibly enter the
database (accessed only through sogo and the funambol connector) and,
more importantly, how to "fix" it now that it's already there?
It's likely one of your funambol devices that generates th
Does anybody know how that (wrong?) data could possibly enter the
database (accessed only through sogo and the funambol connector) and,
more importantly, how to "fix" it now that it's already there?
It's likely one of your funambol devices that generates those bad EXDATE
entries. Mobile devi
En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
While doing the restore, I see a bunch of these messages:
2010-08-30 15:19:25.843 sogo-tool[18846] restoring record '1073742958'
2010-08-30 15:19:25.850 sogo-tool[18846] File NSCalendarDate.m: 1440. In
[NSCalendarDate -initWithYear:
En/na Luca Olivetti ha escrit:
RRULE:FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=22;COUNT=0
EXDATE:2009-11-22;2010-05-22
This is the line causing the "invalid month given".
If I change it to EXDATE:20091122,20100522 it doesn't give that error
message anymore, but it still cannot be edited on the
En/na Luca Olivetti ha escrit:
While doing the restore, I see a bunch of these messages:
2010-08-30 15:19:25.843 sogo-tool[18846] restoring record '1073742958'
2010-08-30 15:19:25.850 sogo-tool[18846] File NSCalendarDate.m: 1440. In
[NSCalendarDate -initWithYear:month:day:hour:minute:second:tim
En/na Luca Olivetti ha escrit:
En/na Wolfgang Sourdeau ha escrit:
Any hint?
There is likely one particular event that causes the issue. What you
might want to do is to extract the event in question. Since the crash
occurs in the reccurence code, you need to search for an element in
your b
19 matches
Mail list logo
