You can find this version at ftp://ftp.isdn4linux.de/pub/isdn4linux/CVS-Snapshots/
Created attachment 41449 [details] isdn4k-utils-20041007.ebuild ebuild for latest CVS snapshot. the portage dir should also contain directory files/20041007 obtained with these commands: mkdir files/20041007 cp files/3.2_p1-r2 files/20041007 cp files/3.2_p1-r4 files/20041007
Created attachment 41450 [details, diff] files/20041007/gentoo.patch gentoo.patch for isdn4k-utils-20041007
it shouldn't compile -- cause of errors in it. as well as the latest capi4k-utils pack in #66797. it must break at capifax/capi.c (one NULL to much in ALERT_REQ)
i am wrong -- only my isdn ebuild uses the capi part. comment is only valid for bug 66797.
I was trying to install the new ebuild but after several attempts I could not succeed. Has the ebuild been tested in a gentoo environment? What I did was copy the ebuild file to /usr/portage/net-dialup/isdn4k-utils, compute a digest and then try an emerge. This failed because it needed several local files, which I tried to put in the rigth places manually but I still can't get it running.
As you can see in comment #1, there is plenty you should do before emerging. It was tested but only as ebuild (compiled and installed). I don't have the neccesary hardware.
OK I apologize for not reading the entire bug report. I followed the instructions and was able to emerge succesfully. Unfortunately I'm lost now in the configuration phase, as I am unfamiliar with ISDN and Linux. I'm only using ISDN for a few weeks waiting for my new ADSL connection, and it doesn't look easy to configure to me. Under Windows it was a breeze.
huaaahhh, it compiles and works ;) btw: 2004-10-24 is available. should go into portage ASAP, since the old ebuild has problems with gcc 3.4!
btw^2: this ebuild should conflict with capi4k-utils, since most files in both packages are dupes (i.e. libcapi20, etc.).
oh, /etc/init.d/capi is missing somehow (see capi4k-utils). How do I initialize the capi via "capiinit"?
isdn4k-utils is not configured to install the included capi part. so there is not interaction between isdn4k-utils and capi4k-utils. there should be no capiinit from isdn4k-utils.
well, but isdn4k-utils installs: /sbin/avmcapictrl /sbin/capiinit /usr/bin/capiinfo /usr/include/capi20.h /usr/include/capicmd.h /usr/include/capiutils.h /usr/lib/libcapi20.a /usr/lib/libcapi20dyn.a /usr/lib/libcapi20.la /usr/lib/libcapi20.so /usr/lib/libcapi20.so.2 /usr/lib/libcapi20.so.2.0.9 all of these files are also included in capi4k-utils. Either we merge both packages, or we have to delete the capi-stuff in isdn4k-utils.
ah, yeah, i didn't get this change "24 Sep 2004 config file improvement". i just copied from the config file from overlay to overlay. ... But now (one time no nonsense in this bug report, please): isdn4k-utils don't install capiplugin (CONFIG_PPPDCAPIPLUGIN=y needed in config) ... Without capiplugin blocking capi4k-utils is no solution.
ehhh, I check the "config" again. But when I emerged this ebuild, I got the mentioned files! no joke!
hmmm, I copied "config" from files/3.2_p1-r4 and I don't find CONFIG_PPPDCAPIPLUGIN in it. But I found this entry: CONFIG_AVMCAPICTRL=y maybe a different "config" would help. But THIS ebuild attached to THIS BugZilla, compiles and installs the mentioned CAPI stuff.
ups. it's late ;-) @tove: now I understood, what you mean. We need a better config-file, then both capi/isdn4k-utils can coexist.
ok, commenting out the following line in "config" disables the creation of all the CAPI stuff: CONFIG_AVMCAPICTRL=y so please comment it out.
I've commited isdn4k-utils-20041024.ebuild to CVS. It should be available shortly. The config is modified according to comment #17. Please test it and return with feedback so I could close this bug.
well. The problem is, that all device-nodes are missing on udev. I know, that is a problem of the kernel stuff. But it would be nice to have a simple dumb straight-forward shellscript, which creates all the device-nodes. They're saved in the udev-tarball, so that script have to be called only once.
oh, another thing: 'isdn4k-utils' installs: /etc/ppp/ioptions /etc/ppp/ip-down /etc/ppp/ip-down.ippp0 /etc/ppp/ip-up /etc/ppp/options.ippp0 'ppp' installs: /etc/ppp/ip-down /etc/ppp/ip-up and both are different and so they overlap. :-/
comment 19: device nodes are created in -r1. please test this new ebuild. comment 20: if the package needs those files, can't do anything about it. besides, all files in /etc are protected, so user will have the chance to choose which file serves him/her best. have you a better idea?
RE: comment 19: I'll test it. RE: comment 20: yes. A better solution would be to suffix these files with a suffix like ".isdn" and then just symlink them if there's no other symlink. same with 'ppp' package. I just can't decide which one to use, when I only see the diff. It would be better to have both and then, when you configure your installation with care and some manuals behind, to decide which one to use. Or maybe some ".example" files or such. At least both packages should be better "integrated". Dupes are always no fun! Sometimes, you can't just install all the stuff a package offers w/o any modification to match the distri's framework.
-r1 creates the device-nodes. But in the scripts/ directory of the tarball, there's a script called "makedev.sh". This one should be installed somehow. If your device-nodes are lost somehow, you could easily recreate them with this script. But it's not a good idea to install it as "makedev.sh" in /usr/sbin. It should be prefixed like: isdn4k-makedev.sh
I've taked a closer look at sources and realised that ebuild name is wrong. I will delete all actual 20041024 versions and release a 3.5_p20041024 with following changes: - makedev.sh will be copied to /usr/share/doc/isdn4k... - ip-up will be the same as in ppp package - ip-down will contain the actual ip-down.ippp0
3.5_p20041024 submitted. Please test it
I'll do it later (I'm @work right now). But we need start/stopt-scripts for all the servers in the isdn4k-utils package. For example 'isdnlog' and others. I try to make some. Next update should include them.
ok, the ebuild itself is ok. But I have some kind of a chicken-egg problem. ;-) I have an AVM B1 which needs a special firmware loaded into the card. This is done with "capiinit" from the capi4k-utils and works perfect. Now I want to use also isdn4k-utils and need "capidrv" as a bridge. If I load the driver *after* capiinit has run, everything works fine. If I try to load it before (or compile it into the kernel), the system hangs when running "capiinit". Since "capidrv" is part of the "old world" there should be some kind of "driver-loader" in the isdn4k-utils package (i.e. as part of a start/stop-script). When I run /etc/init.d/capi in [boot] and /etc/init.d/isdn4linux in [default] and isdn4linux would also load the "capidrv" driver, then it would simply work. Loading the driver in modules.autoload.d or compiling it into the kernel doesn't work and make the system hang. And I mean *really* hang. Even SysRq doesn't work. :-( Any suggestions?
why don't you put something like: depend() { use capi } in /etc/init.d/isdn4linux? Don't need to use boot runlevel to establish a starting order; with use/need flags, you could create chains of dependent services.
that siply doesn't work. this order is important: 1. capi2.0 2. capi-firmware-upload via capiinit 3. capidrv 4. anything that is in isdn4k the missing link is #3. It has to be loaded *after* capiinit (/etc/init.d/capi), but *before* anything in isdn4k-utils. So we either need an own init-script, or we put this functionality in the isdn4linux init-script. Something like: [/etc/conf.d/init4linux] LOAD_MODULES="capidrv" [/etc/init.d/init4linux] for m in $LOAD_MODULES; do modprobe $m; done [..] you get the picture.
ah, now I understand. You have 2 options: - add to init4linux a flashy mechanism of loading $MODULES as is implemented in /etc/init.d/modules. - put "before modules" in capiinit and "after modules" in init4linux
"before modules" isn't a good idea. The solution should work *everywhere* not only on my PC. I prefer a "fancy", "flashy" mechanism like in alsasound. You can configure your isdn-modules in /etc/conf.d/isdn4linux and the init-scrips loads them in a fancy manner (if configured at all). If you leave alone the option, then no modules are loaded. This way, no "dirty tricks" are needed. I will make this init-script and attach it here.
Created attachment 43671 [details] isdn4linux.init updated init-script which optionally loads ISDN drivers and runs always after 'capi' if available.
Created attachment 43672 [details] isdn4linux.conf updated config-file for isdn4linux.init
ok, this works perfect! please update net-dialup/isdn4k-utils-3.5_p20041024. next task is to make some init-scripts for isdnlog & Co. ;-)
do you also want to contribute with a isdnlog init script or should I close this bug?
I want to contribute an isdnlog initscript also. But I still have to figure out the best framework for it. I takes some time. I suggest to include my attached initscript + conf and close this bug for the time being. I will open a new one for the other init-scripts (not only isdnlog, but also vbox and others). I hope you take this bug then. ;-)
isdn4k-utils-3.5_p20041024-r1 submitted. tx Stefan for your help! looking forward to work with you again.
oh, btw: /var/lib/isdn4linux/isdnctrl.conf the path doesn't exist. perhaps the default path should be /etc/isdn/isdnctrl.conf would make much more sense, since it is plain ASCII
ah, my mistake. I've only issued ebuild .. install and look in image directory, in which it is present. Didn't verified that it actualy gets installed. I will solve that right away. I think /var/lib/... is a good path for this kind of dinamic settings. For example, iptables script uses the same repository for iptables-save/iptables-restore configuration save.
ok, but then /var/lib/isdn is the way to go.
ok.. the directory /var/lib/isdn4linux is installed! looking in your init script, I see the file isn't important (it isn't considered an error), so the first time when the service is running it will not load the stored configuration, but it will save it if you run "/etc/init.d/isdn4linux save", very much the same as in iptables! I really don't see any problem. About /var/lib/isdn... Lets call it for a period of time. I think it is best to use the package as is, take note of every improvement you can think of and come again in 2-3 weeks.
ok, I'm working on some enhancements. But it seems, that there're some BIG changes to do, to do it right. I have a SuSE installed on another machine, and SuSE has a huge Framework for it. I try to pick up some of their ideas. btw: /sbin/... is wrong. The binaries should be installed in /usr/sbin/... I will fix this then.
I think suse has good src rpms for stuff like that. SuSE is just the distro that gets the patches and fixes first. So I think we really should take up the suse patches in the capi area.
SuSE is good in doing complicated things simple. But sometimes their scripts are too bloated. I prefer a mix of simplicity combined with a slick design. The ISDN framework from SuSE is too bloated. But they have some nice ideas. And they support more than 1 ISDN-card, even different brands, in 1 PC. They load for every card the right driver and start for every card one isdnlog daemon with its own config. They even have a own sub-init-script for every supported card. Really, that's too bloated for Gentoo. I try to make it much simpler, but w/o loosing the possibility to support more than one card. I want a slick ISDN framework: 1. capi4k framework (mandantory for Kernel 2.6) 2. mISDN and propritary CAPI drivers (as add-on to capi4k) 3. isdn4k framework (old world, capidrv or hisax driver) 4. tools/apps on top of either capi and/or isdn and with minimal configuration afford. 1. install capi4k, eventually some other lowlevel CAPI-driver, make it work with your card(s) with minimal configuration. 2. install isdn4k, configure it with minimal afford, activate included tools such as isdnlog. 3. install ISDN or CAPI applications It should just work.
Stefan, when you are content with your custom ebuild, I'll be more than happy to import it in tree. Till then, I'll solve other bugs; net-dialup still have too many open bugs and my time is a limited resource. :(
hey, that's what I said. I make the new ebuilds, and when I'm finished, I file a new bug for it. Till then: relax ;-)
