| Summary: | net-misc/asterisk[-ssl] installs four unusable modules; any configuration installs at least one; modules selection cleanup | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | Tony Vroon (RETIRED) <chainsaw> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jaco, voip+disabled |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Patch for ebuild and metadata.xml | ||
Tony, Arguments seems solid - I would personally say just drop the SSL flag and force it, however, not everybody may require DUNDI and IAX/2, also consider that func_aes is def not required. I've got USE=ssl so won't be affected, and can easily update our in-house ebuilds to depend on net-misc/asterisk[ssl] as well. +*asterisk-1.8.7.1-r2 (04 Nov 2011) + + 04 Nov 2011; Tony Vroon <chainsaw@gentoo.org> +asterisk-1.8.7.1-r2.ebuild: + Broken SSL USE-flag removed, now hardcoded on. Module selection clean-up by + Diego Elio Pettenò closes bug #389271. |
Created attachment 291495 [details, diff] Patch for ebuild and metadata.xml Basically I found this by chance, as I was trying to remove a few modules on a customer's install, as asterisk was unable to load pbx_dundis.so, chan_iax2.so and func_aes.so because of a missing res_crypto.so (which in turn is caused by USE=-ssl). So I verified a bit the symbols that are exported and used by the modules *on my default configuration* (which means there might be more), with this command: fgrep -w -v -f <( (elfgrep -h -D ^ast usr/lib64/asterisk/modules/*.so usr/sbin/asterisk | cut -c 20- | sort -u; elfgrep -h -U ^ast usr/lib64/asterisk/modules/*.so | cut -c 20- | sort -u; ) | sort | uniq -d ) <(elfgrep -U ^ast usr/lib64/asterisk/modules/*.so) (the elfgrep command is part of dev-ruby/ruby-elf. and I was running it out of a binpkg; that's the bash command, but using zsh and =() instead of <() is highly suggested as grep doesn't seem to be very reliable :( ) On a standard asterisk[ssl] build, it reports this: usr/lib64/asterisk/modules/chan_mgcp.so: U ast_pktccops_gate_alloc and that is because it requires res_pktccops; so I changed the ebuild to enable both together (not sure if you wish to disable them instead, or condition them). Then on an asterisk[-ssl] build I get: usr/lib64/asterisk/modules/func_aes.so: U ast_aes_set_encrypt_key usr/lib64/asterisk/modules/func_aes.so: U ast_aes_set_decrypt_key usr/lib64/asterisk/modules/func_aes.so: U ast_aes_decrypt usr/lib64/asterisk/modules/func_aes.so: U ast_aes_encrypt usr/lib64/asterisk/modules/pbx_dundi.so: U ast_aes_set_encrypt_key usr/lib64/asterisk/modules/pbx_dundi.so: U ast_encrypt_bin usr/lib64/asterisk/modules/pbx_dundi.so: U ast_check_signature_bin usr/lib64/asterisk/modules/pbx_dundi.so: U ast_aes_set_decrypt_key usr/lib64/asterisk/modules/pbx_dundi.so: U ast_aes_decrypt usr/lib64/asterisk/modules/pbx_dundi.so: U ast_decrypt_bin usr/lib64/asterisk/modules/pbx_dundi.so: U ast_key_get usr/lib64/asterisk/modules/pbx_dundi.so: U ast_aes_encrypt usr/lib64/asterisk/modules/pbx_dundi.so: U ast_sign_bin usr/lib64/asterisk/modules/chan_mgcp.so: U ast_pktccops_gate_alloc usr/lib64/asterisk/modules/chan_iax2.so: U ast_aes_set_encrypt_key usr/lib64/asterisk/modules/chan_iax2.so: U ast_sign usr/lib64/asterisk/modules/chan_iax2.so: U ast_aes_set_decrypt_key usr/lib64/asterisk/modules/chan_iax2.so: U ast_check_signature usr/lib64/asterisk/modules/chan_iax2.so: U ast_aes_decrypt usr/lib64/asterisk/modules/chan_iax2.so: U ast_key_get usr/lib64/asterisk/modules/chan_iax2.so: U ast_aes_encrypt so I disabled the three modules noted when ssl USE flag is disabled. And since this makes it a bit non-obvious, I went on to edit metadata.xml to make it clear that without the ssl USE flag, chan_iax2 won't be built. And since it seemed ... long-winded, I've tried refactoring it with the attached patch by making a function to call menuselect without repeating it over and over again. HTH, Diego P.S.: a revbump is definitely required as the installed modules have changed.. if you wish for me to commit this just let me know.