Re: [openchange]Proposing a release

On Fri, 2012-02-10 at 12:37 +0100, Julien Kerihuel wrote:
> We need to cut down a client release including all (and others)
> bugfixes. Even if this means a broken server-package (which by the way
> is fully working on branches but require trunk merge).
> 
> I'll find some time this week-end to send an email to the list for
> review with the entire set of fixes expected to be applied.

	Hi,
I'm currently at revision 3772 of OpenChange trunk, and I'm happy with
it, I can read/send mails, create/modify/delete events, memos, tasks and
contacts, and I can access GAL with NSPI with no issue found.

Let's deal with Shaheed's issues and the OpenChange is ready to be
released, from my point of view (and my testing).

Thanks for it.
	Bye,
	Milan

Re: [openchange]Proposing a release

On Mon, 2012-03-05 at 20:01 +0100, Milan Crha wrote:
> On Fri, 2012-02-10 at 12:37 +0100, Julien Kerihuel wrote:
> > We need to cut down a client release including all (and others)
> > bugfixes. Even if this means a broken server-package (which by the way
> > is fully working on branches but require trunk merge).
> > 
> > I'll find some time this week-end to send an email to the list for
> > review with the entire set of fixes expected to be applied.
> 
> 	Hi,
> I'm currently at revision 3772 of OpenChange trunk, and I'm happy with
> it, I can read/send mails, create/modify/delete events, memos, tasks and
> contacts, and I can access GAL with NSPI with no issue found.
> 
> Let's deal with Shaheed's issues and the OpenChange is ready to be
> released, from my point of view (and my testing).
> 
> Thanks for it.
> 	Bye,
> 	Milan
> 

Shaheed SeekEntries patch entered trunk today.

Waiting for your feedback on last libmapi pending patch and for Wolfgang
possible remaining patch on server's side and we'll be ready for
shipping OpenChange 1.0.

Kind Regards,
Julien.

Re: [openchange]Proposing a release

On Tue, 2012-03-06 at 15:14 +0100, Julien Kerihuel wrote:
> Shaheed SeekEntries patch entered trunk today.

	Hi,
here's a patch for PT_MV_CLSID support in cast_mapi_SPropValue(), which
Shaheed tested. Please include it too.

> Waiting for your feedback on last libmapi pending patch and for Wolfgang
> possible remaining patch on server's side and we'll be ready for
> shipping OpenChange 1.0.

Sounds good.
	Thanks and bye,
	Milan

_______________________________________________
devel mailing list
devel <at> lists.openchange.org
http://mailman.openchange.org/listinfo/devel

Re: [openchange]Proposing a release

Hi

Patch applied in r3797.

Thanks,

Julien.

On Wed, 2012-03-07 at 07:47 +0100, Milan Crha wrote:
> On Tue, 2012-03-06 at 15:14 +0100, Julien Kerihuel wrote:
> > Shaheed SeekEntries patch entered trunk today.
> 
> 	Hi,
> here's a patch for PT_MV_CLSID support in cast_mapi_SPropValue(), which
> Shaheed tested. Please include it too.
> 
> > Waiting for your feedback on last libmapi pending patch and for Wolfgang
> > possible remaining patch on server's side and we'll be ready for
> > shipping OpenChange 1.0.
> 
> Sounds good.
> 	Thanks and bye,
> 	Milan
> _______________________________________________
> devel mailing list
> devel <at> lists.openchange.org
> http://mailman.openchange.org/listinfo/devel

[openchange]OpenChange 1.0 BORG Released!

The OpenChange project team is happy to announce a new release (1.0
"Borg") is now available for download.

This release is designed to work with the "alpha 18" release of Samba4.

OpenChange 1.0 provides a working server implementation with support
among other numerous features for cached mode and notifications (MAPI
but also from external services such as Dovecot). It is working with all
Outlook versions and is using SOGo backend for OpenChange as primary
storage backend for this release.

OpenChange client libraries have also been greatly improved with the
help of developers using it within their development (e.g.
evolution-mapi). See the CHANGELOG file in the tarball for full details.

The team would like to thank everyone who helped in making this release,
including:
Olly Betts
Milan Crha
Shaheed Haque
Mathieu Patou
Aaron Small
Wolfgang Sourdeau

We'd also like to acknowledge the continued support of the Microsoft
"Dochelp" team - much appreciated.

This release can be downloaded from
http://tracker.openchange.org/projects/openchange/files

Re: [openchange]OpenChange 1.0 BORG Released!

On Thu, 2012-03-15 at 16:58 +0100, Julien Kerihuel wrote:
> The OpenChange project team is happy to announce a new release (1.0
> "Borg") is now available for download.

	Hi,
congratulation for the 1.0 achievement. Good job.
	Bye,
	Milan

Re: [openchange]OpenChange 1.0 BORG Released!

+1

On 15 March 2012 16:04, Milan Crha <mcrha <at> redhat.com> wrote:
> On Thu, 2012-03-15 at 16:58 +0100, Julien Kerihuel wrote:
>> The OpenChange project team is happy to announce a new release (1.0
>> "Borg") is now available for download.
>
>        Hi,
> congratulation for the 1.0 achievement. Good job.
>        Bye,
>        Milan
>
> _______________________________________________
> devel mailing list
> devel <at> lists.openchange.org
> http://mailman.openchange.org/listinfo/devel
_______________________________________________
devel mailing list
devel <at> lists.openchange.org
http://mailman.openchange.org/listinfo/devel

Re: [openchange]OpenChange 1.0 BORG Released!

Hi all,

Something seems to have changed in the way that GetProps and
GetPropsAll are supposed to work. Since I upgraded to Samba18 and
BORG, these calls are not fetching properties with names of the form
PidLidxxx any more. Something related which *has* changed is that I
now need to include one of two files I did not previously need that
defines these names, namely one of:

#include </usr/local/include/libmapi/mapi_nameid.h>
//#include </usr/local/include/mapistore/mapistore_nameid.h>

Is it significant that these two files have different values for the
same name? Clues appreciated!

Thanks, Shaheed

On 16 March 2012 17:29, Shaheed Haque <srhaque <at> theiet.org> wrote:
> +1
>
> On 15 March 2012 16:04, Milan Crha <mcrha <at> redhat.com> wrote:
>> On Thu, 2012-03-15 at 16:58 +0100, Julien Kerihuel wrote:
>>> The OpenChange project team is happy to announce a new release (1.0
>>> "Borg") is now available for download.
>>
>>        Hi,
>> congratulation for the 1.0 achievement. Good job.
>>        Bye,
>>        Milan
>>

Re: [openchange]OpenChange 1.0 BORG Released!

Hi,

I think there is an issue in automatically mapping and unmapping
PidLidXxx items.

At present, my code is blissfully unaware of the special handling of
PidLixXxx items. I simply ask for PidLidAppointmentRecur, call
GetProps (without asking for the named id skipping), and look at the
returned values using PidLidAppointmentRecur.

I will look into this to see if I can pin down what is going wrong,
but would appreciate any input on changes in this area since I am
pretty much unable to progress at the moment.

Thanks, Shaheed

On 17 March 2012 00:05, Shaheed Haque <srhaque <at> theiet.org> wrote:
> Hi all,
>
> Something seems to have changed in the way that GetProps and
> GetPropsAll are supposed to work. Since I upgraded to Samba18 and
> BORG, these calls are not fetching properties with names of the form
> PidLidxxx any more. Something related which *has* changed is that I
> now need to include one of two files I did not previously need that
> defines these names, namely one of:
>
> #include </usr/local/include/libmapi/mapi_nameid.h>
> //#include </usr/local/include/mapistore/mapistore_nameid.h>
>
> Is it significant that these two files have different values for the

Re: [openchange]OpenChange 1.0 BORG Released!

So, watch what happens as I step through the loop in
mapi_nameid_unmap_SPropTagArray, when called from inside GetProps...

(gdb) n
742
SPropTagArray->aulPropTag[mapi_nameid->entries[i].position] = (enum
MAPITAGS) mapi_nameid->entries[i].proptag;
(gdb)
740             for (i = 0; i < mapi_nameid->count; i++) {
(gdb)
741                     if (mapi_nameid->entries[i].position <=
SPropTagArray->cValues) {

*** I am still in the loop. Let's just check the entry to hand.

(gdb) p mapi_nameid->entries[i]
$98 = {
  proptag = 2182480130,
  OOM = 0x7f9e8b43e681 "ApptRecur",
  lid = 33302,
  Name = 0x0,
  propType = 258,
  ulKind = 0 '\000',
  OLEGUID = 0x7f9e8b43e578 "00062002-0000-0000-c000-000000000046",
  position = 13
}

*** Notice the position in this entry 13, so let's just check what is
in the output array at position 13, and confirm it is different than
the proptag in the entry: