SASL lib 2.1.24

Thu Apr 14 10:15:43 EDT 2011

Hi!

> >My favourite (and I think I also speak for Dan White who made this 
> >patch) is:
> >
> >http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3186
> >
>
> A minor variation of this patch was committed yesterday.

Great. I have tried again with a clean checkout: Works for me!

> >2. Applying it to the Debian package source - still didn't work. So I 
> >did some more hacking.
> >
> Can you be more specific?

That problem also disappeared now, so if it's not broken, don't fix it.

The problem was something like:

Part of the patch is the makeinit.sh script, which is a script that modifies or generates C source code at some point in the build process. The Debian build process actually builds the lib twice for two different flavours of Kerberos, IIUC. And for some strange reason I possibly applied the patch to that makeinit.sh script at the wrong point in time, so it did not have the desired effect, so I worked around it with a plain copy of a modified source file.

But again, problem solved. So we now have a version in CVS which builds without any additional patches including the LDAP module. My test build did not include the gs2 module, I think, possibly because some prerequisite is missing, but to me that is a detail of Debian packaging then. I am still trying to understand what I would ever need GSSAPI and GS2 for. I know what I need LDAP for.

So thanks for committing that patch.

The next things I will do is:

1. update the stuff in my Ubuntu PPA with today's CVS version (I will let the list know once that happened)

2. test my newly built Debian squeeze packages with today's CVS version (the fact that it builds doesn't mean it works, as we know) - in case anyone is interested in a Debian PPA kind of thing; I may be able to provide one or at least offer the modified source package for anyone who wants to try them to be built in a pbuilder environment

3. Pre-sort the list of currently 26 patches in the Debian package for SASL lib 2.1.23 and identify those who are NOT Debian adjustments and provide them for review (what format?)

I will happily work with Debian developers to get the 2.1.24 packaged so it may eventually show up on Debian backports for 6.0 as well as Ubuntu Natty backports and be included in Debian 7.0 / Ubuntu 11.10 hopefully.

But this process can only start after the Cyrus project will have released 2.1.24. Before that the Debian / Ubuntu devleopers will not be interested in the subject. "New upstream release" is usually the trigger they need.

But prior to releasing 2.1.24 it may indeed make sense to melt down the list of Debian patches. I guess they have been made for a reason.

Are there any other open bugs / features / patches which would need to make it into 2.1.24?

I think there was some MaxOS stuff ...

Is anyone keeping a list?

Regards,
Torsten

-------- Original-Nachricht --------
> Datum: Thu, 14 Apr 2011 11:00:05 +0100
> Von: Alexey Melnikov <alexey.melnikov at isode.com>
> An: Torsten Schlabach <TSchlabach at gmx.net>
> CC: cyrus-devel at lists.andrew.cmu.edu
> Betreff: Re: SASL lib 2.1.24

> Torsten Schlabach wrote:
> 
> >Hi!
> >
> Hi Torsten,
> 
> >>I would appreciate opinions on which bugs/patches people consider to be 
> >>important.
> >>    
> >>
> >
> >My favourite (and I think I also speak for Dan White who made this patch)
> is:
> >
> >http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3186
> >
> >  
> >
> A minor variation of this patch was committed yesterday.
> 
> >Without that one, the build fails on compile if you do
> >
> >configure --enable-ldap
> >
> >which is what the Debian and Ubuntu package build does.
> >
> >I guess many of you just don't do --enable-ldap? Otherwise everybody must
> have stumbled over that, right?
> >
> >Unfortunately I had the following problem with that patch:
> >
> >1. Applying it to the tarball - fine.
> >  
> >
> Good.
> 
> >2. Applying it to the Debian package source - still didn't work. So I did
> some more hacking.
> >
> Can you be more specific?
> 
> >Talking Debian:
> >
> >Right now the Debian package has 20+ patches applied to the original
> source.
> >
> >Some of them are Debian specific, so that's fine. But I am sure not all
> of them are. So it would also be a nice task to see which of these patches
> make sense and should go into the package and which of them have been
> obsoleted anyway in the meanwhile but just don't apply properly any more due to
> code changes.
> >  
> >
> I am happy to review, if you point me to the list.
> 
> >I know my comments are not very actionable, but sometimes I just loose
> track on what's my fault and what's a problem in the code. So prior to
> blaming anyone, I will rather double-check. But I will take the time and come
> back to the problems I found and report them properly.
> >
> >Would it be good practise to file a bug for each problem?
> >
> Yes, but it might be better to post a list of issues to the mailing list 
> first, so that people can sanity check and tell which problems are real 
> and which are not.
> 
> >One thing I found regarding gs2:
> >
> >I didn't see an --enable-gs2 / --disbale-gs2 option in the help output of
> configure. I haven't tested if it would work or not, but I *think* I tried
> to build my package with --disbale-gs2 and it did *not* get me around.
> >
> There is no --enable-gs2 at the moment. If --enable-gssapi is used, both 
> the GSSAPI and the GS2 plugins are built. Configure should now properly 
> detect whether required gssapi.h functions are present and disable GS2 
> if they are not.
> 
> >Please stay tuned for details; I need to re-test that tomorrow, but the
> working day is pretty much over in this part of the world.
> >
> >Talking about the release number:
> >
> >As there has never been a 2.1.24 and I think few people ever cared about
> 2.1.24rc1, why would we jump to 2.1.25?
> >
> There were some significant changes from 2.1.24 (and possibly some minor 
> API changes), so I would rather bump the version number to be on the 
> safe side. Note that it is not possible to get the "rc1" part from the 
> libsasl (there is a version query function in it).
> 
> >The other question is: What's the rule to jump from 2.1.x to 2.2?
> >
> I don't know the answer to this question. Most likely major public API 
> changes.
> 
> >What was the trigger to jump from 1.x to 2.x?
> >
> There were some major API changes, some callback changed their lists of 
> parameters, etc. In general case it is not possible to build a program 
> that works with both versions of the API, unless some ifdefs are used.
> 
> Best Regards,
> Alexey
> 
> -- 
> Internet Messaging Team Lead, <http://www.isode.com>
> JID: same as my email address
> twitter: aamelnikov
> 