Re: libzephyr and notifications
On 2012-05-29 1:38, Greg Banks wrote: Ok, I'll review that, starting today or tomorrow (flu permitting). I saw Andreas' message go past but I can't seem to find it now that I need it :( so what's the git URL? He's git://github.com/aosowski/cyrus-imapd.git The branch is ticket/3605 Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08
Re: libzephyr and notifications
Hi, I'm very sorry that Andreas done my job to rebase against the current master... I plan to do some cleanup of my code : I need to use commit 6735484f76470b02c439cc553149b0beb0e34e81 from branch dev/sieve/vacation-seconds (instead of mine 77cab79f920629a964340cfcfff14338f161a3c1), merge some commits into one to clean up the history, and finally export IMAP URL into the external form. Sébastien 2012/5/29 Jeroen van Meeuwen (Kolab Systems) : > On 2012-05-29 1:38, Greg Banks wrote: >> >> Ok, I'll review that, starting today or tomorrow (flu permitting). I >> saw Andreas' message go past but I can't seem to find it now that I need >> it :( so what's the git URL? > > > He's git://github.com/aosowski/cyrus-imapd.git > > The branch is ticket/3605 > > > Kind regards, > > Jeroen van Meeuwen > > -- > Systems Architect, Kolab Systems AG > > e: vanmeeuwen at kolabsys.com > m: +44 74 2516 3817 > w: http://www.kolabsys.com > > pgp: 9342 BF08
ABI change in cyrus sasl 2.1.25
Hi, [speaking about: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3692] is there a timeframe for releasing 2.1.26? The ABI change should have changed and this is causing some havoc in OpenLDAP runtimes, thus it would be really nice to have fixed version with bumped SONAME. I don't want to bump SONAME solely in Debian package since it would break compatibility across the ecosystems, but we are discussing doing that even though it will create some problems later. So it would be really nice if you could just release 2.1.26 or 2.1.25.1 (whatever suits you) with bumped SONAME. O. -- Ondřej Surý
Re: ABI change in cyrus sasl 2.1.25
On 29/05/2012 15:15, Ondřej Surý wrote: Hi, Hi Ondřej, Coincidentally I just started discussing your bug with Ken 15 mins ago. [speaking about: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3692] is there a timeframe for releasing 2.1.26? The ABI change should have changed and this is causing some havoc in OpenLDAP runtimes, thus it would be really nice to have fixed version with bumped SONAME. I don't want to bump SONAME solely in Debian package since it would break compatibility across the ecosystems, but we are discussing doing that even though it will create some problems later. So it would be really nice if you could just release 2.1.26 or 2.1.25.1 (whatever suits you) with bumped SONAME. Reading the bug you submitted (and references), it looks like the original problem was against 2.1.24. 2.1.25 was released since then. Was there another instance of an incompatible ABI change since then? As far as changing ABIs (or adding new APIs) is concerned: In saslplug.h: #define SASL_UTILS_VERSION 5 is bumped when sasl_utils structure is changed incompatibly (e.g. addition of new struct members which will grow the struct size. Changing a "spare_XXX" doesn't count, as long as such members are optional). #define SASL_CLIENT_PLUG_VERSION 4 is bumped when the "struct sasl_client_plug" or related functions change. #define SASL_SERVER_PLUG_VERSION 5 is bumped when "struct sasl_server_plug" or related functions change. #define SASL_CANONUSER_PLUG_VERSION 5 is bumped when "struct sasl_canonuser" or related functions change. #define SASL_AUXPROP_PLUG_VERSION 9 Is bumped on any auxprop_* API changes. I have updated this version when I changed auxprop_lookup. And then there is the version number in sasl.h, which should change when there are any other semantics changes or changes to APIs (including addition of new functions). As far as 2.1.26 is concerned. I've started on it now. There are a couple of blocker bugs that I would like to resolve (1 of them is under control and just needs testing). If I am lucky, this will take about 2 weeks to wrap up. Best Regards, Alexey
Re: ABI change in cyrus sasl 2.1.25
Just quick reply from my phone. No additional breakage, I just opened the bug after some longer time and didn't realize it applies to 2.1.24. Ondřej Surý On 29. 5. 2012, at 16:46, Alexey Melnikov wrote: > On 29/05/2012 15:15, Ondřej Surý wrote: >> Hi, > Hi Ondřej, > Coincidentally I just started discussing your bug with Ken 15 mins ago. >> [speaking about: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3692] >> >> is there a timeframe for releasing 2.1.26? >> >> The ABI change should have changed and this is causing some havoc in >> OpenLDAP runtimes, thus it would be really nice to have fixed version >> with bumped SONAME. I don't want to bump SONAME solely in Debian >> package since it would break compatibility across the ecosystems, but >> we are discussing doing that even though it will create some problems >> later. >> >> So it would be really nice if you could just release 2.1.26 or >> 2.1.25.1 (whatever suits you) with bumped SONAME. > > Reading the bug you submitted (and references), it looks like the original > problem was against 2.1.24. 2.1.25 was released since then. > Was there another instance of an incompatible ABI change since then? > > > > As far as changing ABIs (or adding new APIs) is concerned: > > In saslplug.h: > > #define SASL_UTILS_VERSION 5 > > is bumped when sasl_utils structure is changed incompatibly (e.g. addition of > new struct members which will grow the struct size. Changing a "spare_XXX" > doesn't count, as long as such members are optional). > > > #define SASL_CLIENT_PLUG_VERSION 4 > > is bumped when the "struct sasl_client_plug" or related functions change. > > > #define SASL_SERVER_PLUG_VERSION 5 > is bumped when "struct sasl_server_plug" or related functions change. > > > #define SASL_CANONUSER_PLUG_VERSION 5 > > is bumped when "struct sasl_canonuser" or related functions change. > > > #define SASL_AUXPROP_PLUG_VERSION 9 > > Is bumped on any auxprop_* API changes. I have updated this version when I > changed auxprop_lookup. > > And then there is the version number in sasl.h, which should change when > there are any other semantics changes or changes to APIs (including addition > of new functions). > > > > As far as 2.1.26 is concerned. I've started on it now. There are a couple of > blocker bugs that I would like to resolve (1 of them is under control and > just needs testing). If I am lucky, this will take about 2 weeks to wrap up. > > Best Regards, > Alexey >
Re: ABI change in cyrus sasl 2.1.25
On 29/05/2012 15:54, Ondřej Surý wrote: Just quick reply from my phone. No additional breakage, I just opened the bug after some longer time and didn't realize it applies to 2.1.24. Ok, please double check. I will do 2.1.26 anyway, but it would be good to close the bug if it no longer applies. Ondřej Surý On 29. 5. 2012, at 16:46, Alexey Melnikov wrote: On 29/05/2012 15:15, Ondřej Surý wrote: Hi, Hi Ondřej, Coincidentally I just started discussing your bug with Ken 15 mins ago. [speaking about: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3692] is there a timeframe for releasing 2.1.26? The ABI change should have changed and this is causing some havoc in OpenLDAP runtimes, thus it would be really nice to have fixed version with bumped SONAME. I don't want to bump SONAME solely in Debian package since it would break compatibility across the ecosystems, but we are discussing doing that even though it will create some problems later. So it would be really nice if you could just release 2.1.26 or 2.1.25.1 (whatever suits you) with bumped SONAME. Reading the bug you submitted (and references), it looks like the original problem was against 2.1.24. 2.1.25 was released since then. Was there another instance of an incompatible ABI change since then? As far as changing ABIs (or adding new APIs) is concerned: In saslplug.h: #define SASL_UTILS_VERSION 5 is bumped when sasl_utils structure is changed incompatibly (e.g. addition of new struct members which will grow the struct size. Changing a "spare_XXX" doesn't count, as long as such members are optional). #define SASL_CLIENT_PLUG_VERSION 4 is bumped when the "struct sasl_client_plug" or related functions change. #define SASL_SERVER_PLUG_VERSION 5 is bumped when "struct sasl_server_plug" or related functions change. #define SASL_CANONUSER_PLUG_VERSION 5 is bumped when "struct sasl_canonuser" or related functions change. #define SASL_AUXPROP_PLUG_VERSION 9 Is bumped on any auxprop_* API changes. I have updated this version when I changed auxprop_lookup. And then there is the version number in sasl.h, which should change when there are any other semantics changes or changes to APIs (including addition of new functions). As far as 2.1.26 is concerned. I've started on it now. There are a couple of blocker bugs that I would like to resolve (1 of them is under control and just needs testing). If I am lucky, this will take about 2 weeks to wrap up. Best Regards, Alexey
Re: ABI change in cyrus sasl 2.1.25
I don't think 2.1.25 bumped SONAME, so the bug still applies. As for the #defines - they are related to API (e.g. compile time), but already compiled programs linked against cyrus-sasl (e.g. runtime) will experience the breakage. Ondřej Surý On 29. 5. 2012, at 16:57, Alexey Melnikov wrote: > On 29/05/2012 15:54, Ondřej Surý wrote: >> Just quick reply from my phone. >> >> No additional breakage, I just opened the bug after some longer time and >> didn't realize it applies to 2.1.24. > > Ok, please double check. I will do 2.1.26 anyway, but it would be good to > close the bug if it no longer applies. > >> Ondřej Surý >> >> On 29. 5. 2012, at 16:46, Alexey Melnikov wrote: >> >>> On 29/05/2012 15:15, Ondřej Surý wrote: Hi, >>> Hi Ondřej, >>> Coincidentally I just started discussing your bug with Ken 15 mins ago. [speaking about: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3692] is there a timeframe for releasing 2.1.26? The ABI change should have changed and this is causing some havoc in OpenLDAP runtimes, thus it would be really nice to have fixed version with bumped SONAME. I don't want to bump SONAME solely in Debian package since it would break compatibility across the ecosystems, but we are discussing doing that even though it will create some problems later. So it would be really nice if you could just release 2.1.26 or 2.1.25.1 (whatever suits you) with bumped SONAME. >>> Reading the bug you submitted (and references), it looks like the original >>> problem was against 2.1.24. 2.1.25 was released since then. >>> Was there another instance of an incompatible ABI change since then? >>> >>> >>> >>> As far as changing ABIs (or adding new APIs) is concerned: >>> >>> In saslplug.h: >>> >>> #define SASL_UTILS_VERSION 5 >>> >>> is bumped when sasl_utils structure is changed incompatibly (e.g. addition >>> of new struct members which will grow the struct size. Changing a >>> "spare_XXX" doesn't count, as long as such members are optional). >>> >>> >>> #define SASL_CLIENT_PLUG_VERSION 4 >>> >>> is bumped when the "struct sasl_client_plug" or related functions change. >>> >>> >>> #define SASL_SERVER_PLUG_VERSION 5 >>> is bumped when "struct sasl_server_plug" or related functions change. >>> >>> >>> #define SASL_CANONUSER_PLUG_VERSION 5 >>> >>> is bumped when "struct sasl_canonuser" or related functions change. >>> >>> >>> #define SASL_AUXPROP_PLUG_VERSION 9 >>> >>> Is bumped on any auxprop_* API changes. I have updated this version when I >>> changed auxprop_lookup. >>> >>> And then there is the version number in sasl.h, which should change when >>> there are any other semantics changes or changes to APIs (including addition >>> of new functions). >>> >>> >>> >>> As far as 2.1.26 is concerned. I've started on it now. There are a couple >>> of blocker bugs that I would like to resolve (1 of them is under control >>> and just needs testing). If I am lucky, this will take about 2 weeks to >>> wrap up. >>> >>> Best Regards, >>> Alexey >>> >
Re: ABI change in cyrus sasl 2.1.25
On 29/05/2012 16:11, Ondřej Surý wrote: I don't think 2.1.25 bumped SONAME, so the bug still applies. Please explain what "bumping SONAME" means. I've asked Ken and neither of us understands. As for the #defines - they are related to API (e.g. compile time), but already compiled programs linked against cyrus-sasl (e.g. runtime) will experience the breakage. Ondřej Surý On 29. 5. 2012, at 16:57, Alexey Melnikov wrote: On 29/05/2012 15:54, Ondřej Surý wrote: Just quick reply from my phone. No additional breakage, I just opened the bug after some longer time and didn't realize it applies to 2.1.24. Ok, please double check. I will do 2.1.26 anyway, but it would be good to close the bug if it no longer applies. Ondřej Surý On 29. 5. 2012, at 16:46, Alexey Melnikov wrote: On 29/05/2012 15:15, Ondřej Surý wrote: Hi, Hi Ondřej, Coincidentally I just started discussing your bug with Ken 15 mins ago. [speaking about: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3692] is there a timeframe for releasing 2.1.26? The ABI change should have changed and this is causing some havoc in OpenLDAP runtimes, thus it would be really nice to have fixed version with bumped SONAME. I don't want to bump SONAME solely in Debian package since it would break compatibility across the ecosystems, but we are discussing doing that even though it will create some problems later. So it would be really nice if you could just release 2.1.26 or 2.1.25.1 (whatever suits you) with bumped SONAME. Reading the bug you submitted (and references), it looks like the original problem was against 2.1.24. 2.1.25 was released since then. Was there another instance of an incompatible ABI change since then? As far as changing ABIs (or adding new APIs) is concerned: In saslplug.h: #define SASL_UTILS_VERSION 5 is bumped when sasl_utils structure is changed incompatibly (e.g. addition of new struct members which will grow the struct size. Changing a "spare_XXX" doesn't count, as long as such members are optional). #define SASL_CLIENT_PLUG_VERSION 4 is bumped when the "struct sasl_client_plug" or related functions change. #define SASL_SERVER_PLUG_VERSION 5 is bumped when "struct sasl_server_plug" or related functions change. #define SASL_CANONUSER_PLUG_VERSION 5 is bumped when "struct sasl_canonuser" or related functions change. #define SASL_AUXPROP_PLUG_VERSION 9 Is bumped on any auxprop_* API changes. I have updated this version when I changed auxprop_lookup. And then there is the version number in sasl.h, which should change when there are any other semantics changes or changes to APIs (including addition of new functions). As far as 2.1.26 is concerned. I've started on it now. There are a couple of blocker bugs that I would like to resolve (1 of them is under control and just needs testing). If I am lucky, this will take about 2 weeks to wrap up. Best Regards, Alexey
Re: ABI change in cyrus sasl 2.1.25
Still writing from tiny device... When you change interface and break binary compatibility you need to increase .so.NUMBER. Existing binaries has to be recompiled to use this new library. And older binaries can still use older version of the library without breaking. I can prepare patch... There is also some short info here: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi Ondřej Surý On 29. 5. 2012, at 17:25, Alexey Melnikov wrote: > On 29/05/2012 16:11, Ondřej Surý wrote: >> I don't think 2.1.25 bumped SONAME, so the bug still applies. > > Please explain what "bumping SONAME" means. I've asked Ken and neither of us > understands. > >> As for the #defines - they are related to API (e.g. compile time), but >> already compiled programs linked against cyrus-sasl (e.g. runtime) will >> experience the breakage. >> >> Ondřej Surý >> >> On 29. 5. 2012, at 16:57, Alexey Melnikov wrote: >> >>> On 29/05/2012 15:54, Ondřej Surý wrote: Just quick reply from my phone. No additional breakage, I just opened the bug after some longer time and didn't realize it applies to 2.1.24. >>> Ok, please double check. I will do 2.1.26 anyway, but it would be good to >>> close the bug if it no longer applies. >>> Ondřej Surý On 29. 5. 2012, at 16:46, Alexey Melnikov wrote: > On 29/05/2012 15:15, Ondřej Surý wrote: >> Hi, > Hi Ondřej, > Coincidentally I just started discussing your bug with Ken 15 mins ago. >> [speaking about: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3692] >> >> is there a timeframe for releasing 2.1.26? >> >> The ABI change should have changed and this is causing some havoc in >> OpenLDAP runtimes, thus it would be really nice to have fixed version >> with bumped SONAME. I don't want to bump SONAME solely in Debian >> package since it would break compatibility across the ecosystems, but >> we are discussing doing that even though it will create some problems >> later. >> >> So it would be really nice if you could just release 2.1.26 or >> 2.1.25.1 (whatever suits you) with bumped SONAME. > Reading the bug you submitted (and references), it looks like the > original problem was against 2.1.24. 2.1.25 was released since then. > Was there another instance of an incompatible ABI change since then? > > > > As far as changing ABIs (or adding new APIs) is concerned: > > In saslplug.h: > > #define SASL_UTILS_VERSION 5 > > is bumped when sasl_utils structure is changed incompatibly (e.g. > addition of new struct members which will grow the struct size. Changing > a "spare_XXX" doesn't count, as long as such members are optional). > > > #define SASL_CLIENT_PLUG_VERSION 4 > > is bumped when the "struct sasl_client_plug" or related functions change. > > > #define SASL_SERVER_PLUG_VERSION 5 > is bumped when "struct sasl_server_plug" or related functions change. > > > #define SASL_CANONUSER_PLUG_VERSION 5 > > is bumped when "struct sasl_canonuser" or related functions change. > > > #define SASL_AUXPROP_PLUG_VERSION 9 > > Is bumped on any auxprop_* API changes. I have updated this version when > I changed auxprop_lookup. > > And then there is the version number in sasl.h, which should change when > there are any other semantics changes or changes to APIs (including > addition > of new functions). > > > > As far as 2.1.26 is concerned. I've started on it now. There are a couple > of blocker bugs that I would like to resolve (1 of them is under control > and just needs testing). If I am lucky, this will take about 2 weeks to > wrap up. > > Best Regards, > Alexey > >
Re: ABI change in cyrus sasl 2.1.25
On 29/05/2012 17:10, Ondřej Surý wrote: Still writing from tiny device... When you change interface and break binary compatibility you need to increase .so.NUMBER. Existing binaries has to be recompiled to use this new library. And older binaries can still use older version of the library without breaking. I can prepare patch... There is also some short info here: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi If you can prepare the patch, that would be great. Will save me time anyway ;-).
Re: ABI change in cyrus sasl 2.1.25
On Tue, May 29, 2012 at 6:16 PM, Alexey Melnikov wrote: > On 29/05/2012 17:10, Ondřej Surý wrote: >> >> When you change interface and break binary compatibility you need to >> increase .so.NUMBER. Existing binaries has to be recompiled to use this new >> library. And older binaries can still use older version of the library >> without breaking. Let me explain in greater detail now. cyrus-sasl now produces: library: /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25 symlink: /usr/lib/x86_64-linux-gnu/libsasl2.so.2 Binaries (as for example slapd) are linked to libsasl2.so.2 (which is the SONAME) and dynamic linker looks for this file in it's paths. When you break binary compatibility as happened in 2.1.24 you need to increase SONAME of the library to something higher (usually just increase it by one). So cyrus-sasl >= 2.1.24 should really have: libsasl2.so.3 SONAME. Also as one can see the last (patch) number of the library matches the release, which is also probably wrong. You need to change the number only in case you actually change something in the ABI (like add a new function). You can read more about Library interfaces in the libtool manual, especially this part is relevant: http://www.gnu.org/software/libtool/manual/libtool.html#Versioning Here are a set of rules to help you update your library version information: 1. Start with version information of ‘0:0:0’ for each libtool library. 2. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster. 3. If the library source code has changed at all since the last update, then increment revision (‘c:r:a’ becomes ‘c:r+1:a’). 4. If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0. 5. If any interfaces have been added since the last public release, then increment age. 6. If any interfaces have been removed or changed since the last public release, then set age to 0. >> I can prepare patch... >> >> There is also some short info here: >> >> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi > > > If you can prepare the patch, that would be great. Will save me time anyway > ;-). Will do, but not today :). O. -- Ondřej Surý
cyrus-sasl: cmulocal/ direcotry and pkg-config
Hello, while we are on cyrus-sasl issues: Does the change of the ABI in cyrus-sasl require changes in cyrus-imapd? I guess no, since it was reported that the ABI changed in 2.1.24 and I use 2.1.25. But anyway, would it be possible to use pkg-config with cyrus-sasl 2.1.26, that installs a file $(pkgdatadir)/cyrus-sasl.pc, so that cyrus-imapd and other packages can use pkg-config`s autoconf macros to check for the version of cyrus-imapd ? If yes, I can provide patches for pkg-config support on cyrus-sasl . If cyrus-sasl 2.1.26 uses pkg-config, would it be acceptable for cyrus-imapd 2.5 to require cyrus-sasl 2.1.26 <=> replace the autoconf macros for finding cyrus-imapd with the pkg-config-autoconf macros PKG_CHECK_MODULES? What is the rule to update the cmulocal/ directory in cyrus-imapd? I have read somewhere that it is shared between cyrus-imapd and cyrus-sasl, but despite of this I have put in cyrus-imapd:master/cmulocal AS_HELP_STRING to AC_ARG_ENABLE and AC_ARG_WITH . What is the procedure to update the cyrus-imapd/cmulocal directory, if it is shared with cyrus-sasl? Greetings Dilian - Message from Ondřej Surý - Date: Tue, 29 May 2012 16:15:51 +0200 From: Ondřej Surý Subject: ABI change in cyrus sasl 2.1.25 To: cyrus-devel@lists.andrew.cmu.edu Hi, [speaking about: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3692] is there a timeframe for releasing 2.1.26? The ABI change should have changed and this is causing some havoc in OpenLDAP runtimes, thus it would be really nice to have fixed version with bumped SONAME. I don't want to bump SONAME solely in Debian package since it would break compatibility across the ecosystems, but we are discussing doing that even though it will create some problems later. So it would be really nice if you could just release 2.1.26 or 2.1.25.1 (whatever suits you) with bumped SONAME. O. -- Ondřej Surý - End message from Ondřej Surý -
