Asterisk has included the ability to manage voicemail via an IMAP server. It requires c-client source code from UW-Imap, http://www.washington.edu/imap/, yet when I have net-mail/uw-imap installed asterisk cannot find it. This could be an issue with upstream, I am not sure, but there is no USE flag for it either in the ebuild. Reproducible: Always Steps to Reproduce: 1. emerge =net-mail/uw-imap 2. emerge =net-misc/asterisk-1.6.2.5 Actual Results: IMAP support in installed asterisk in not installed. Expected Results: When installing net-misc/asterisk-1.6.2.5 either a USE flag for IMAP or IMAP support is included by default. http://www.asterisk.org/astdocs/node232.html Digium documentation on how to build Asterisk with IMAP support.
There is no USE-flag because nobody has managed to provide working IMAP support yet. I've tried and users have tried, the closest we got was something that compiled but didn't load. If you have patches (which should apply to 1.6.2.6 and result in a working build), feel free to reopen this bug.
(In reply to comment #1) > There is no USE-flag because nobody has managed to provide working IMAP support > yet. I've tried and users have tried, the closest we got was something that > compiled but didn't load. > If you have patches (which should apply to 1.6.2.6 and result in a working > build), feel free to reopen this bug. > I'm not sure I can re-open this, but I did get it working. The hack is ugly, but doesn't blow up portage. I'm going to refine it if possible to build against system libs so is like a normal ebuild dependency rather than built in ${S}... though that should possibly be an *option*, since the IMAP libs aren't linked anyway and can be gone after asterisk build. Hmm. It may be good enough as is, then. But I'm also building against 1.6.1.14, so will need to update my own system to 1.6.2 first, before this can be resolved as requested. The thing is so under-documented that most of the problem for me was getting it to work once installed. Anyway, more to come soon...
Created attachment 225161 [details, diff] patch to 1.6.2.6 ebuild provide imap There are comments in the ebuild. IDK if this is the best or worst way, portage/PM-wise but it is what needs to happen to build, more or less. And it surely can be improved in places. But hey, proof of concept??? '-)
Created attachment 225247 [details] Fix broken configure.ac to allow detection of system c-client Hi, I was looking for this too, and got a little further ahead. I know why the configure script won't find the installed c-client. Checking configure.log, when ./configure compiles it's test program to check for the system c-client, it won't complete because our c-client system library requires -lpam and -lssl to work correctly. A simple patch to the configure.ac script fixes this. I am attaching it here. I created this on the 1.6.1 asterisk, but I tested it on 1.6.2.6 and it still works fine. As for the ebuild, I was taking a different approach. I was using the asterisk described method of /etc/asterisk.makeopts to specify IMAP storage of voicemails, but I assume we can use the old version to choose it. I haven't tested that yet. I think collectively we can get this solved. -- Steve
Created attachment 225269 [details, diff] much less ugly patch to add imap Moved needed patch (to use system c-client imap libs) to configure.ac to a sed edit and removed all my nonsense to build c-client in "${S}"
Thank you, will audit these soon. Hopefully Monday.
@michael_higgins: I tested your new ebuild with my existing imap-enabled system this weekend and it compiled fine. As a note, I removed my /etc/asterisk.makeopts and used your methods. IMAP is working correctly and message counts are good. I can also retrieve them via my phones. -- Steve
Michael, thanks so much for breathing some life back into this bug. It is of considerable interest to me and I have long been meaning to put this particular feature into production. I haven't yet had an opportunity to test your patch but look forward to doing so (with 1.4, in my case). Recently, I've been concentrating on re-factoring my ebuild in various respects and, based on what I've done so far, would like to suggest something. That is, I don't think that the use of a custom makeopts file should be dependent on any given flag being used. Here's how I'm currently handling it. As an early step in src_configure (my ebuild is EAPI-2 compliant): # This will contain custom options that are superimposed upon the defaults. touch "${T}"/gentoo.makeopts The src_compile function is simply as follows: src_compile() { ASTLDFLAGS="${LDFLAGS}" emake USER_MAKEOPTS="${T}"/gentoo.makeopts || die "emake failed" } In this way, the ebuild is somewhat simplified. Moreover, it paves the way for other build options to be added. I've found that asterisk can cope with having make invoked with USER_MAKEOPTS defined, provided that the file it refers to exist - even if it is blank (in which case it has no effect on the defaults). While the following snippet has no bearing on this particular bug, it's a good example of how I'm already leveraging this approach in a useful manner. To whit, making the debug USE flag actually behave in a useful manner: if use debug; then local debug_opts="DEBUG_CHANNEL_LOCKS DEBUG_THREADS DEBUG_FD_LEAKS" # Tone down the compiler flags somewhat. This should be less aggressive # than the DONT_OPTIMIZE option whilst still producing useful results. # strip-flags replace-flags -O? -O0 einfo "Enabling debugging options: ${debug_opts}" echo "MENUSELECT_CFLAGS=${debug_opts}" >> "${T}"/gentoo.makeopts fi Also - and apologies for nitpicking - is there a reason for the `if [ -z "$( use imap )"];' syntax? I think that `if use imap;' would serve the purpose just as well.
Also, by "this bug" I was really referring to bug 265567 which, of course, suffered from never getting so far as to prescribe a solution!
(In reply to comment #8) > Michael, thanks so much for breathing some life back into this bug. Seems enough interest all around, hopefully, to put it down. > I don't think that the use of a custom makeopts file should be dependent on any > given flag being used. Hmm. Not to disagree per se, but if I'd enabled USE="imap" and got imap storage for voicemail with having never looked at the ebuild, I'd be quite happy. Not needing SMTP for e-voicemail access... seems prudent in some situations, maybe? Personally, so as long as there's a 'gentoo' way easy to suss out, I'm neutral on it. But, wasn't the other bug resolved by removing the imap use flag? > > Here's how I'm currently handling it. > src_compile() { > ASTLDFLAGS="${LDFLAGS}" emake USER_MAKEOPTS="${T}"/gentoo.makeopts || die > "emake failed" > } Right. This approach was suggested on a mailing list, is where I got it. And, offhand, IDK what ${T} is. Temp folder? I'd not known about these makeopts files before looking at this bug, and knowing about them doesn't, eh, bring me joy. I'd personally prefer the ebuild make a sane set for revising makeopts based on what I've USEd. > In this way, the ebuild is somewhat simplified. Moreover, it paves the way for > other build options to be added. I've found that asterisk can cope with having > make invoked with USER_MAKEOPTS defined, provided that the file it refers to > exist - even if it is blank (in which case it has no effect on the defaults). > My concern wrt use flags and auto-magical makeopts was whether it would *override* /etc/asterisk.makeopts or ~/asterisk.makeopts(?) Probably we can just include them in the VAR we re-define should they exist, no? > Also - and apologies for nitpicking - is there a reason for the `if [ -z "$( > use imap )"];' syntax? I think that `if use imap;' would serve the purpose just as well. > LOL! Because I *don't know what I am doing*. And hey, what I had in there before was *so* embarrassingly wrong... even I saw it. Really, I'd prefer leave it up to y'all with a bit more history as to the finer details. My point, hopefully made, is that it seems not that hard -- if I can (sort of) do it -- to make it so to have USE="imap" and the installation DWIM "as advertised" "out of the box".
Re: Comment 10 >> I don't think that the use of a custom makeopts file should be dependent on >> any given flag being used. > >Hmm. Not to disagree per se, but if I'd enabled USE="imap" and got imap storage >for voicemail with having never looked at the ebuild, I'd be quite happy. Not needing SMTP for e-voicemail access... seems prudent in some situations, maybe? I meant it quite literally; my recommendation goes beyond the scope of what any given feature in asterisk actually does. As it stands, your ebuild patch would have emake invoked with USER_MAKEOPTS _only_ where the imap USE flag is set. Note that this is a separate concern from populating the file that USER_MAKEOPTS in the first instance based on the fact that IMAP support was desired. For argument's sake, let's assume that my revamped USE="debug" support (or, indeed, any patch to the ebuild that entailed further population of the USER_MAKEOPTS file, conditional or otherwise) were to be added. We'd end up with a situation such as this: if use imap || use debug; then # Treat emake as a special case here ... fi For any additional options that entailed population of the USER_MAKEOPTS file, this condition would become even more convoluted over time. If we used this, or that, or that ... What I'm saying is that it doesn't need to be treated as a special case at all. The process can be as thus: 1) touch the USER_MAKEOPTS file 2) populate the file conditionally based on whatever the user so desires 3) always invoke emake with the USER_MAKEOPTS file As previously mentioned, when the USER_MAKEOPTS parameter refers to an empty file, it has no impact upon the manner in which asterisk is built at all. So, as long it is touched, we don't need to check for anything at step (3) - rather, one can merely concentrate on step (2). And, if nothing happens during step (2), that's also fine as it doesn't change anything. > Right. This approach was suggested on a mailing list, is where I got it. And, > offhand, IDK what ${T} is. Temp folder? Yes, it's the temp folder within the sandbox. This is what I have in my ebuild right now, so I just pasted it as such. I'm not particularly concerned as whether it's ${S} or ${T}. In fact, ${S} probably makes more sense when the USE="keepsrc" flag is taken into consideration! > My concern wrt use flags and auto-magical makeopts was whether it would > *override* /etc/asterisk.makeopts or ~/asterisk.makeopts(?) Probably we can > just include them in the VAR we re-define should they exist, no? I don't quite follow. As far as options entailed by USE flags are concerned, they should absolutely override any aspect in which the build would otherwise have proceeded (this is their remit after all)! With regard to auto-magical options as a general topic, the ebuild - like others I am beginning to discover in the portage tree at large - has QA issues that are caused by not being comprehensively explicit about ./configure options. To provide but one example, I discovered that, if the prerequisites for h323 support are discovered to be present by its build system, asterisk will attempt to compile in h323 support irrespective of whether one has requested it or not (it's no use just to drop support for the h323 flag and pretend it is no longer a factor). Worse, it fails. The solution, of course, is to hard-code --without-h323 based on the fact that we do not support it, nor is there a USE flag for it. And, so it should go for other relevant options. However, this ought to be the topic of another bug and I intend to open one once I've completed my work in this regard :) However, it does collectively raise one point which I think is very much related to the notion of going down the road of leveraging USER_MAKEOPTS. Because the USER_MAKEOPTS file is effectively superimposed upon asterisk's upstream defaults, it might not be a bad idea to sit down at some point and reflect upon whether the the upstream defaults make sense in their current state. It's all well and good where we enable a feature through custom makeopts population which was not otherwise enabled in upstream's makeopts, but what if we find ourselves in a situation where we want to disable something in such a manner that requires makeopt adjustment (as opposed to a less-granular or non-existent ./configure option)? Anyway, I fear I'm going very off-topic with respect to this bug. To summarise, there's nothing wrong with the way in which IMAP support has been implemented here except that I'm suggesting that we don't need the specification of USER_MAKEOPTS as an emake parameter to be conditional. That was all.
Having looked at this further, there are several issues that spring to my mind: 1) As far as I know, conditional patching is not OK in QA terms (i.e. no sed) 2) It's not safe to assume that c-client was built against pam/openssl 3) If asterisk is built with USE="imap ssl", then c-client should have been built with USE="ssl". 4) Similarly, if asterisk is built with USE="imap -ssl", then c-client should have been built with USE="-ssl" 5) flameyes contributed a patch prior to all of this which handled some quirk involving kerberos support that may still be relevant Regarding (1) and (2), I'm trying to figure out a decent solution. I'll do my best to file some patches by the end of tomorrow as I'm very keen to move things forwards. I'm thinking that we should do something like this: local imap_libs [ built_with_use net-libs/c-client pam ] && imap_libs="-lpam" [ built_with_use net-libs/c-client ssl ] && imap_libs="${imap_libs} -lssl" ... then figure out a nice way to propagate this to configure.ac (which might involve the consistent application of one patch which would alleviate the QA concern). Regarding (3) and (4), the ebuild once got this right before the imap USE flag was dropped. Here's how it can be done if EAPI=2 is declared: RDEPEND="imap? ( ssl? ( net-libs/c-client[ssl] ) !ssl? ( net-libs/c-client[-ssl] ) )" Regarding (5), the original patches were "asterisk-1.4.24-imap-kerberos.patch" and "asterisk-1.6.1-imap-kerberos.patch". I don't fully understand them so I'm going to contact flameeyes.
Diego, would you be so kind as to offer an opinion on Comment 12? I want to avoid conditional patching but am not sure how to go about it in this instance. Some information regarding the kerberos patch would also be most welcome.
Uhm, okay, let me try to sum up some notes here ^^ First, seems like the problem is due to c-client only building a static archive, and not providing a -config script or a pkg-config data file to tell what to link to (nor a .la file). For what concerns the libraries: local imap_libs [ built_with_use net-libs/c-client pam ] && imap_libs="-lpam" [ built_with_use net-libs/c-client ssl ] && imap_libs="${imap_libs} -lssl" should probably be rewritten to has_version =net-libs/c-client[pam] to avoid the deprecated built_with_use. If that's done, you can pass extra libraries to link to through configure by just calling it with econf LIBS="${imap_libs}" without patching it at all… although that *will* link them everywhere and not just where you need them. You *could* make configure.ac have a --with-extra-c-client libraries otherwise. And you can simplify the dependency as net-libs/c-client[ssl=] by the way.
Please note that this should be rebased to 1.6.2.8 (with Diego's comments addressed) before it can be looked at. Thank you.
This no longer applies and the feedback from Diego has not been taken into account. Feel free to reopen the bug once this has been rectified.
Let's try to get this settled once and for all. I tried defining LIBS but, interestingly, it doesn't work (it either fails to build or doesn't have the desired effect; I can't remember which as it was quite a long time ago that I tried it). I do not care for this option anyway. I also considered the possibility of defining an extract configure option but I am not keen on the idea because (a) my autotools skills are poor (b) more pertinently, I want the downstream modifications to be as simple as possible, both in terms of integration and bringing forwards to future ebuilds. However, I did immediately take into consideration the two QA improvements that Diego suggested, which have subsequently been kicking around in my personal 1.4 ebuild for some time. It occurred to me that asterisk's build system already responds to various environment variables, so why not simply add another? That requires a trivial one-line change in configure.ac (so no more sed hacks). I will now attach two patches, one of which is intended for placement in ${FILESDIR}/1.6.2 and the other of which is a patch against the current asterisk-1.6.2.13-r2.ebuild. As per my earlier ramblings, this also adds unconditional support for custom menuselect options by way of a gentoo.makeopts file. It is currently only used for enabling imap storage but could easily be used for other things. In particular, consider that it would be quite possible to 'seed' gentoo.makeopts by copying a skeleton file from ${FILESDIR}. This in turn makes it easy to customise the upstream defaults, should that ever be desired, even before going through the process of performing conditional customisation based on USE flags.
Created attachment 255581 [details, diff] asterisk-1.6.2.13-imap-libs.patch Simply adds IMAP_LIBS as a supported variable in the relevant code path of configure.ac
Created attachment 255583 [details, diff] Patch against asterisk-1.6.2.13-r2.ebuild
*** Bug 265567 has been marked as a duplicate of this bug. ***
I have seen this working on the 1.4 branch briefly, but an upstream change broke it. Most of the work on this was done by Kerin Millar, who has told me that he is no longer interested in working with me. As such, I have no recourse but to close this bug. If anyone is willing to do a patch against current 1.6.2 and/or 1.8 ebuilds in the tree, I am of course interested. However, can I ask that you file me a new report when you do. Thank you.
