Hello, we have created a patched dahdi-2.2.1 ebuild with vzaphfc support that is directly usable with single and multiport hfc (cologne) cards in TE mode. An asterisk ebuild, which also provides NT mode is also available. The setup is in productive use with asterisk 1.6.2 in at least 2 machines and working without any problems. I wrote a gentoo tutorial today with an installation description at http://blog.flemming.info/?p=51 and a second tutorial with a debug description at http://blog.flemming.info/?p=74. A third german tutorial has been written by Larry and is available at http://com-in.de/index.php/howto-asterisk-hfc-gentoo. ( Thanks to Larry for his great work.) All ebuilds are available for a local overlay and we will also attach them to this thread. Could one of the maintainers please have a look at our ebuilds and see if they are interesting to be included in the official tree. Stefan
Patches are as follows
Created attachment 222405 [details] ebuild for dahdi-2.2.1 patched ebuild from dahdi-2.2.0.2
Created attachment 222407 [details, diff] core-timer patch for dahdi as described on <http://lists.digium.com/pipermail/dahdi-commits/2009-July/001192.html>
Created attachment 222409 [details, diff] oslec echo canceller - ripped from kernel-2.6.32
Created attachment 222411 [details, diff] the vzaphfc module from <http://code.google.com/p/zaphfc/>
Created attachment 222413 [details, diff] the vzaphfc module (newer version - cut doesn't work for me, DOH!)
Created attachment 222415 [details, diff] enables the above patches in dahdi
Created attachment 222417 [details] the appropriate ebuild for dahdi-tools-2.2.1 stupid copy of dahdi-tools-2.2.0-r1
Created attachment 222419 [details] NT-PTMP enabled ebuild for asterisk-1.6.2.5
Created attachment 222421 [details, diff] NT-PTMP patch
My thoughts on USE flags: - It may be useful to build oslec only when use-flag 'ecoslec' is given - The core-timer patch enables dahdi's own timer, because the cheap HFC cards doesn't have any timer in HW, so this is a need for vzaphfc. Other cards *have* a timer in HW (i.e. cards from Digium, HFC based cards with more than one Port). I don't know whats happen when dahdi's core-timer is enabled but a card/device-driver depends on its own timer, so enabling the core-timer patch globally seems to be a bad idea. The next thing would be: Whats happen when mixing a cheap HFC and a Digium? Therefore I suggest a 'vzaphfc' use-flag to indicate that the user want's (only) the vzaphfc module. A change to the above dahdi ebuild has to be done then.
Hi Oliver, thank you for your submission. So we can now also link against the ebuilds in this bug... We also have to change the header and check again if emerge/unmerge -deep works correct, now. I had a problem once with the dahdi ebuild when installing with -Dup but can currently not conform it. The system is still in use without any problems. Stefan
Also, note the existence of bug 302874. It's just a routine bump, but offers what I believe to be a correctly implemented parallel make patch and two other minor improvements which you may wish to include.
Created attachment 222619 [details] ebuild for dahdi-2.2.1 with updated USE flags USE flags 'ecoslec' and 'zaphfc' are now optional
Created attachment 222621 [details, diff] enables the oslec patch in dahdi when USE 'ecoslec' is given
Created attachment 222623 [details, diff] enables the vzaphfc patch in dahdi when USE 'zaphfc' is given
Created attachment 222625 [details, diff] parallel-make patch adopted from bug http://bugs.gentoo.org/show_bug.cgi?id=302874
Hi, I point out bug #296637 - which already describes a working oslec patch that is much less intrusive into the dahdi code itself and actually just relies on the kernel module begin present. I also point to bug #302316 which not only contains a patch for the HFC-S chips, but also voicetronix and openvox, without the need for massive intrusion into dahdi core code.
Well, our main goal is to get a working module for hfc-s cards as easy as possible. There's a major need for this - at least here in germany. Our decision to _not_ use the kernel module from users kernel is that user has to ensure to enable oslec/echo from staging and rebuild his kernel/modules, if not already done. So from our sight its easier (or user friendlier) just to integrate oslec into dahdi and to enable it in dahdi's Kbuild, as designed from Digium (see line #35 + #40 in dahdi's Kbuild). This "trick" is working very stable for me since many months in my productive asterisk-system (built with the old zaphfc+bristuff+flortz patches). The next thing is that we don't have any voicetronix nor openvox HW at hand we could test on. Our intention is to gain a working and stable module for hfc-s cards, as pointed out above. The only "intrusion" into dahdi core code (I think you meant the core-timer patch) seems to be a "need" - at least if no other "timing capable" device (like Digium E100p and such) is available (see comment #3 also). We're looking forward into this how to distinguish this...maybe via a use flag. But feel free to merge/comment/add code - you're welcome :)
Created attachment 223253 [details, diff] Small patch to sanitize udev's complains about xpp.rules
Created attachment 223255 [details] ebuild for dahdi-2.2.1 with updated USE flags and sanitized xpp.rules for udev
Created attachment 226427 [details] ebuild for the new dahdi-2.2.1.1 package
Created attachment 226429 [details, diff] core-timer patch for dahdi
Created attachment 226431 [details, diff] GCC 4.4 compatibility patch
Created attachment 226433 [details, diff] enables the oslec patch in dahdi when USE 'ecoslec' is given
Created attachment 226435 [details, diff] enables the vzaphfc patch in dahdi when USE 'zaphfc' is given
Created attachment 226437 [details, diff] no-depmod patch
Created attachment 226439 [details, diff] oslec echo canceller - ripped from kernel-2.6.32
Created attachment 226441 [details, diff] parallel-make patch
Created attachment 226443 [details, diff] Small patch to sanitize udev's complains about xpp.rules
Created attachment 226445 [details, diff] the vzaphfc module from <http://code.google.com/p/zaphfc/>
Created attachment 226449 [details] the appropriate ebuild for the new dahdi-tools-2.2.1.1 package
Created attachment 226451 [details, diff] ifreq patch
Created attachment 226453 [details, diff] modprobe-suffix patch
Created attachment 226455 [details, diff] no-hardware-fiddling patch
Created attachment 226457 [details, diff] vendorlib patch
Created attachment 227103 [details] updated ebuild of dahdi-tools-2.2.1.1 to fix a problem with parallel making When parallel making is used (as with distcc or icecc) it might happen that 'make install' breaks emerge process. In my case I was using MAKEOPTS="-j16" in make.conf and it was impossible to complete the install. I borrowed the idea of fixing this from the dahdi-ebuild files.
Created attachment 227105 [details, diff] parallel-make patch
+*dahdi-2.2.1.1 (13 Apr 2010) + + 13 Apr 2010; <chainsaw@gentoo.org> +dahdi-2.2.1.1.ebuild: + Version bump, incorporating patches, bug reports, suggestions & other + helpful input from Stefan Flemming, Michael Higgins, Oliver Jaksch, Jaco + Kroon, Kerin "kerframil" Millar & Diego E. "Flameeyes" Pettenò. Closes + bugs #296637, #302316, #302874, #305533, #308099 & #308467.
Thanks for merging. But I found at least one bug: In line #28 of dahdi-2.2.1.1.ebuild you set RDEPEND="net-misc/asterisk" which means that asterisk will get emerged first, which fails 'cause dahdi ist missing. My suggestion ist to set RDEPEND="".
Oliver, thanks for picking up on that. I've filed bug 315201 accordingly. If you discover any further issues, please do not hesitate to follow suit and submit new bugs as appropriate.
(In reply to comment #41) > Oliver, thanks for picking up on that. I've filed bug 315201 accordingly. If > you discover any further issues, please do not hesitate to follow suit and > submit new bugs as appropriate. Well then, opened a new bug http://bugs.gentoo.org/show_bug.cgi?id=315237 for request/testing dahdi&dahdi-tools-2.3.0
