Re: new features with no documentation
> Thanks for the explanation. What happens is that at least Cal/CardDAV > compile and work well without libchardet (at least under normal > circumstances) and, as it was not marked as required, I thought it's an > optional lib and here is the question of why to use it. Actually, the same happens with transfig, libsrs2 and shapelib. The page mentiones these libs, but "Required for `make check`" (not sure what that means in relation to the lib being reqiured for cyrus-imapd as such) for all of them is "no". What would help is a column "required" yes/no and another column "usage in cyrus-imapd" explaining for what exactly it's used. Say if it's for tzdata processing in the TZDist module, then I probably won't build with it as I don't see much use for it (or maybe package it as a flavor). But if it's something essential for a broader functionality like CalDAV itself, then definitely it would be included. But at this moment the Compiling page doesn't provide these details and here we are. On 5/6/20 05:30, Anatoli wrote: > Ellie, > >> libchardet is already listed on the compiling page as being used by >> the CalDAV, CardDAV, and/or JMAP features. You would decide to >> install libchardet based on whether you need these features: if you >> don't enable these features, you don't need it; if you do, you >> probably do. >> >> If you don't have libchardet, Cyrus will not do character-set >> detection. If some piece of data has no character set coming in, it >> will have no character set. I don't know why you would decide to not >> use this, and it may simply become a mandatory requirement for these >> features in 3.4. It might have been mandatory in 3.2, if this had >> been brought to our attention during the nearly 3 month beta window; >> but now that it's in a stable release, it will remain as it is. > > Thanks for the explanation. What happens is that at least Cal/CardDAV > compile and work well without libchardet (at least under normal > circumstances) and, as it was not marked as required, I thought it's an > optional lib and here is the question of why to use it. > > I guess what you could do for 3.2 is to include a warning in configure > explaining the issue, so the maintainers see it and take appropriate > action. I suppose there are not that many installations with 3.2 yet so > if the warning is included with 3.2.2 it would be an appropriate time. > > Regards, > Anatoli > > On 4/6/20 21:58, ellie timoney wrote: >> On Thu, Jun 4, 2020, at 12:52 PM, Anatoli wrote: chardet is used by the JMAP module of httpd to detect the character >>> set of untagged 8-bit headers. >>> >>> Does that mean that these libs are required? If not, what would happen >>> if not included? How Cyrus would detect the charset? Or put in other >>> words, if they are not required, what's the benefit to use them? >>> >>> On the other hand, may I suggest to please add these details to the >>> Compiling [1] page? There's already a lot of useful information, but >>> some of the libs lack any details on what's their purpose in Cyrus and >>> why they are beneficial/required (and if they are not used yet, maybe >>> they shouldn't be mentioned there at all?). This could help porters and >>> maintainers to make more educated decisions on how to package Cyrus. >> >> libchardet is already listed on the compiling page as being used by the >> CalDAV, CardDAV, and/or JMAP features. You would decide to install >> libchardet based on whether you need these features: if you don't enable >> these features, you don't need it; if you do, you probably do. >> >> If you don't have libchardet, Cyrus will not do character-set detection. If >> some piece of data has no character set coming in, it will have no character >> set. I don't know why you would decide to not use this, and it may simply >> become a mandatory requirement for these features in 3.4. It might have >> been mandatory in 3.2, if this had been brought to our attention during the >> nearly 3 month beta window; but now that it's in a stable release, it will >> remain as it is. >> >> cld2 was used by one (or maybe both) of the experimental search features >> that were accidentally included in 3.2.0, and removed in 3.2.1 (see the >> release notes). Looks like we forgot to remove the configure checks for the >> library when removing the feature(s) that used it. You don't need it, and >> if you have it, it won't be used anyway. >> >> Cheers, >> >> ellie >>
Re: new features with no documentation
Ellie, > libchardet is already listed on the compiling page as being used by > the CalDAV, CardDAV, and/or JMAP features. You would decide to > install libchardet based on whether you need these features: if you > don't enable these features, you don't need it; if you do, you > probably do. > > If you don't have libchardet, Cyrus will not do character-set > detection. If some piece of data has no character set coming in, it > will have no character set. I don't know why you would decide to not > use this, and it may simply become a mandatory requirement for these > features in 3.4. It might have been mandatory in 3.2, if this had > been brought to our attention during the nearly 3 month beta window; > but now that it's in a stable release, it will remain as it is. Thanks for the explanation. What happens is that at least Cal/CardDAV compile and work well without libchardet (at least under normal circumstances) and, as it was not marked as required, I thought it's an optional lib and here is the question of why to use it. I guess what you could do for 3.2 is to include a warning in configure explaining the issue, so the maintainers see it and take appropriate action. I suppose there are not that many installations with 3.2 yet so if the warning is included with 3.2.2 it would be an appropriate time. Regards, Anatoli On 4/6/20 21:58, ellie timoney wrote: > On Thu, Jun 4, 2020, at 12:52 PM, Anatoli wrote: >>> chardet is used by the JMAP module of httpd to detect the character >> set of untagged 8-bit headers. >> >> Does that mean that these libs are required? If not, what would happen >> if not included? How Cyrus would detect the charset? Or put in other >> words, if they are not required, what's the benefit to use them? >> >> On the other hand, may I suggest to please add these details to the >> Compiling [1] page? There's already a lot of useful information, but >> some of the libs lack any details on what's their purpose in Cyrus and >> why they are beneficial/required (and if they are not used yet, maybe >> they shouldn't be mentioned there at all?). This could help porters and >> maintainers to make more educated decisions on how to package Cyrus. > > libchardet is already listed on the compiling page as being used by the > CalDAV, CardDAV, and/or JMAP features. You would decide to install > libchardet based on whether you need these features: if you don't enable > these features, you don't need it; if you do, you probably do. > > If you don't have libchardet, Cyrus will not do character-set detection. If > some piece of data has no character set coming in, it will have no character > set. I don't know why you would decide to not use this, and it may simply > become a mandatory requirement for these features in 3.4. It might have been > mandatory in 3.2, if this had been brought to our attention during the nearly > 3 month beta window; but now that it's in a stable release, it will remain as > it is. > > cld2 was used by one (or maybe both) of the experimental search features that > were accidentally included in 3.2.0, and removed in 3.2.1 (see the release > notes). Looks like we forgot to remove the configure checks for the library > when removing the feature(s) that used it. You don't need it, and if you > have it, it won't be used anyway. > > Cheers, > > ellie >
Re: configure: wslay v1.1.1 required but the latest one is 1.1.0
Ellie, You're right, I haven't checked well the dates! I just asked the author of Wslay if he could tag a new release. Hope we get an answer soon. Regards, Anatoli On 4/6/20 21:10, ellie timoney wrote: > The commit was authored in 2015, but the pull request was only merged to > wslay master last November. The fix is not in 1.1.0, but it's also not in > our cyruslibs version (unless my submodule is out of date, which it might be, > but I thought I updated it correctly the other day). > > So, since the fix is not in 1.1.0, that would be a problem for Cyrus if Cyrus > depends on the fix being there. I don't know whether it does, or how to test > it. > > On Thu, Jun 4, 2020, at 10:18 AM, Anatoli wrote: >> Ken, >> >> Why do you believe it could be an issue with Cyrus? It appears the fix >> was commited 4 years ago and that part was revorked later, so it should >> not be a problem anymore in 1.1.0. >> >> >> On 3/6/20 07:44, Ken Murchison wrote: >>> Yes, 1.1.0 is probably sufficient, unless this bug is an issue with Cyrus: >>> https://github.com/tatsuhiro-t/wslay/pull/47 >>> >>> >>> On 6/3/20 1:19 AM, ellie timoney wrote: Cool, thanks for confirming that. So far it's sounding like 1.1.0 is probably adequate, but I'll wait a little bit to see if Ken has any input once he's been online On Wed, Jun 3, 2020, at 2:58 PM, Anatoli wrote: > Hi Ellie, > >> When you configure it with your patch applied and 1.1.0 installed, > does Cyrus build okay? > > Yes, it builds without errors. > > Configure prints: > > checking for WSLAY... yes > wslay: yes > > And -lwslay is passed as arg numerous times during build process. > > And effectively httpd binary includes references to wslay_event_xxx in > its symbols table. > > Regards, > Anatoli > > On 3/6/20 01:35, ellie timoney wrote: >> In our "cyruslibs" package, the wslay submodule is at this commit: >> >> commit 4a937cd (HEAD, origin/master, origin/HEAD, master) >> Author: Tatsuhiro Tsujikawa >> AuthorDate: Fri Jun 8 23:19:03 2018 +0900 >> Commit: Tatsuhiro Tsujikawa >> CommitDate: Fri Jun 8 23:19:03 2018 +0900 >> >> Bump up version number to 1.1.1-DEV >> >> Which is the commit immediately following the release-1.1.0 tag. So, >> presumably, we're not dependent on any feature/fix that's only in the >> unreleased version, because otherwise we would've bumped the cyruslibs >> submodule to include those commits? >> >> So, "1.1.1" might be a typo, or an anticipatory thing that didn't go >> anywhere yet, I'm not sure. >> >> When you configure it with your patch applied and 1.1.0 installed, does >> Cyrus build okay? >> >> Cheers, >> >> ellie >> >> On Wed, Jun 3, 2020, at 2:13 PM, Anatoli wrote: >>> Cyrus developers, >>> >>> The configure script checks for wslay lib version 1.1.1, but the latest >>> version released is 1.1.0. So when it is installed, it reports: >>> >>> checking for WSLAY... no >>> configure: httpd will not have support for WebSockets. Consider >>> installing libwslay >>> >>> The wslay's github repo has a mention of a 1.1.1-DEV version. Not sure >>> if cyrus-imapd httpd requires something from it or if it was just a >>> typo and 1.1.0 is ok. >>> >>> For the later case below is a patch. >>> >>> Regards, >>> Anatoli >>> >>> >>> diff --git a/configure.ac b/configure.ac >>> index dc0e0fff2..30e925c60 100644 >>> --- a/configure.ac >>> +++ b/configure.ac >>> @@ -1631,7 +1631,7 @@ dnl AC_MSG_WARN([Your version of >>> OpenDKIM can not support iSchedu >>> >>> AC_ARG_WITH(wslay, [AS_HELP_STRING([--without-wslay], [disable >>> WebSockets support (check)])],,[with_wslay="check"]) >>> if test "x$with_wslay" = "xyes" -o "x$with_wslay" = "xcheck"; >>> then >>> - PKG_CHECK_MODULES([WSLAY], [libwslay >= 1.1.1], [ >>> + PKG_CHECK_MODULES([WSLAY], [libwslay >= 1.1.0], [ >>> AC_DEFINE(HAVE_WSLAY,[], >>> [Build WebSockets support into >>> httpd?]) >>> with_wslay=yes >>> >>
