Well, I've updated my Gentoo box to the new ebuild and now I'm getting error messages during boot up: FATAL: Module kernelcapi not found. FATAL: Module capi not found. FATAL: Module capidrv not found. The problem is that I've module, that are build into the kernel, therefore they could not be found. Please correct this, the message are annoying. Thanks.
capidrv is optional. It's just the bridge to the old-world. There should be no warning, I will fix it. But: kernelcapi and capi are needed if you have a CAPI based card. Perhaps I should also hide these messages for the ppl who statically compiled that stuff into the kernel. But other may want to see if these modules are missing. Hard to deal with it. For the time beeing, if anything works fine, you should ignore the messages or fix it by yourself: [/etc/init.d/capi] /sbin/modprobe -s kernelcapi /sbin/modprobe -s capi /sbin/modprobe -s capidrv just change the "-s" to "-sq" and modprobe shuts up.
How about a conf.d configuration option, e.g. CAPI_BUILD_IN="true" [true|false]? IMHO the better way is to create an autodetection if the module is compiled into the kernel or not, e.g. alsa-utils do the same through analysing the output of modprobe -c.
I think autodetection is a good idea. Stefan, can you attach a verified init.d script that load kernelcapi,capi and capidrv modules only if they exists? Also, see the remove part in stop() function.
can you post your output of "modprobe -c" (as an attachment, please)? I have to be sure that I can find the needed entries even if they are compiled into kernel.
all in all "modprobe -sq <module>" should be enough to hide any error messages. But I want display them, if you either don't have the loadable modules or the compiled-in modules.
Well, you could check if CAPI is installed into running kernel with cat /lib/modules/$(uname -r)/build/.config | grep "CONFIG_ISDN_CAPI=m" (for compiled as module) or find /lib/modules/$(uname -r) -name "MODULE" cat /lib/modules/$(uname -r)/build/.config | grep "CONFIG_ISDN_CAPI=y" (for compiled into kernel) same for CONFIG_ISDN_CAPI_CAPI20 and CONFIG_ISDN_CAPI_CAPIFS to get the information if a module is loaded on system start (with /etc/modules.autoload.d/kernel-2.x) you could use "modprobe -c". My output doesn't matter because the module is either loaded on system boot as module nor afterwards. Other init.d-scripts which didn't use an autodetect supress boot error through "&>/dev/null" (e.g. modules, net.ppp0, alsasound, localmount, lm_sensors) I think it is a good idea to autodetect the presens of a module and display when something went wrong.
"&>/dev/null" is obsolete if you use -q. the other examples are not really portable between Kernel 2.4/2.6 and furthermore very slow and ugly. I try to find a better solution. If I don't find one, I will offer an option in /etc/conf.d/capi to disable these warnings.
btw: checking if capi is installed is quite easy: /proc/capi exists.
fixed in capi4k-utils-20050322
Alin? hell, what are you doing? This CAPI release is INCOMPATIBLE and breaks everything!!!! Please mask it immediately! I'm working with Stefan S. on this issue for a while. And we have a better ebuild almost ready. We wanted to release it this week with fixed/patched ebuilds of capisuite which is broken with capi4k-2005xxxxx. But nonetheless, the next release has this bug fixed.
I am doing exactly what I supposed to do as gentoo dev - maintain my ebuilds. did I missed the memo saying capi4k-utils-2005xxxx is breaking capisuite? I'm not a mind reader, you know... =net-dialup/capi4k-utils-20050322 masked in package.mask
thanks. Sorry for my hard words. I thought you are in contact with Stefan. So you should have known it. btw: I merged some of your code into my ebuild. So your work is not lost ;)
ok, just FYI: the new capi4k-utils installs a libcapi20.so.3 instead of libcapi20.so.2. The ABI/API has changed a little (one added parameter in 3 functions). I checked all capi-applications and most of them are still working fine (obviously they don't use the modified functions). But capisuite is broken. I made a patch for it, but I need time to test ist. Furthermore, 'drdsl' from fcdsl is broken. Since this is binary-only closedsource from AVM, we can't just recompile it. I asked Mr. Schmidt from AVM to resolve this issue, but all I got was another 'drdsl' linking against libcapi20.so.2, so there's no solution on this front right now. ok, my capi4k-utils (current version) will be ready this week. Stefan S. is informed and test it already (both we can, because we have ISDN and many ISDN-devices ;). The new capisuite (-r1) will be released same time (the patch runs only if the new capi 2.0 v3 is found, so you can build it against old and new capi). But there's no solution for 'drdsl'. Perhaps we should check for the new capi in the fcdsl-ebuild and then print an error/warning-message to inform the user. furthermore, I'm working on an update for isdn4k-utils. Nothing breaks with the new release, but I have some enhancements. So it would be nice, if you wait till next week, when I'm hopefully ready. ;)
Stefan, are you aware that I've just bumped isdn4k-utils? it is, of course, marked as ~arch.
since I want to test and debug ebuilds, I run only ~arch ;) That is my latest version: isdn4k-utils-3.7_pre20050326 That is yours: isdn4k-utils-3.7_pre20050329 So I will update it and check what you have done to it and merge your code (if needed). No problem. isdn4k-utils is not the problem, though I have also done some additions (some USE-flags for selecting only parts of the bug bunch, ip-up/down copied from 'ppp', etc.). The problem is/was capi4k, because of the ABI/API change. So that bumb have to be done carefully and all dependent package have to be checked first (not so many). I'm in ICQ with Stefan S. and I try to get my ebuild/changes finished ASAP. He will put it into portage then after a final test. And don't worry, all your changes are included. ;)
I've unmasked the new capi4k-utils
great. thanks.
