as of 2012-01-04 a new version of dahdi was released by digium. no ebuild yet - will try and test next days...
Junghanns.net drivers fail. 2.6.0 is not parallel make clean, even without *any* of our patching applied. If it was easy, I would have done it.
I'm running dahdi-2.6.0 and dahdi-tools-2.6.0 with Asterisk 1.8 and now 10.1. The unpatched version from trunk did compile without problems and works with the Gentoo Asterisk ebuilds. The only thing that I'm missing is oslec. leo*CLI> dahdi show version DAHDI Version: 2.6.0 Echo Canceller: HWEC -- Remote UNIX connection -- Remote UNIX connection disconnected Tony, do I understand correctly that the ebuild cannot be created because we cannot apply all required patches or does the unpatched version not build for you? In the first case we should create an ebuild with all buildable patches and publish it here for further tests.
(In reply to comment #2) > Tony, do I understand correctly that the ebuild cannot be created because we > cannot apply > all required patches or does the unpatched version not build for you? Even the unpatched version dies on parallel make problems. I am not willing to insert -j1 on all the emake statements. (And yes, that is without my parallel make patch!)
Okay, I did not make a parallel compile and you are right, this is indeed an ugly problem. -j1 is not a solution. Have you submitted an issue to the dahdi team?
(In reply to comment #4) > -j1 is not a solution. Have you submitted an issue to the dahdi team? I have not, no. If you submit one, please use the URL field on this bug. (jkroon and I spent some time on getting a workable 2.5.0.2 in the tree and stabled instead)
Has dahdi-2.5.0.2-r2 been tested with actual hardware? or only been checked to see if it compiles? I ask because last week around the time I upgraded dahdi-2.4.1-r1 to the current stable version, I began having problems on my PSTN trunk whereby if I make a call from my SNOM sip phone to asterisk through the TDM400P card to the PSTN, the called party can hear me perfectly, but I get a bad choppy connection where I can only hear parts of the conversation. I tried upgrading to testing asterisk-10.1.0 with no luck. I also upgraded to current stable gentoo-sources-3.2.1-r2, still with no luck. Unfortunately, I can't roll back to 2.4.1-r1. I grabbed a copy of the 2.4.1-r1 ebuild, but I can't download a patchset: # ebuild dahdi-2.4.1-r1 digest !!! Couldn't download 'gentoo-dahdi-patchset-0.6.tar.bz2'. Aborting. !!! Fetch failed for gentoo-dahdi-patchset-0.6.tar.bz2, can't update Manifest From Flemming's comment it appears possible to compile dahdi-2.6 but without OSLEC line echo cancellation for now. Since I switched to OSLEC way back in the zaptel days, I've never had echo problems and so I'm reluctant to try the other software line echo cancellation algorithms.
(In reply to comment #6) > Has dahdi-2.5.0.2-r2 been tested with actual hardware? Obviously. > Unfortunately, I can't roll back to 2.4.1-r1. So you had a regression that you failed to report to me. I never remove ebuilds that I know to be useful to people. Hiding bugs from me makes my job more difficult.
Uhrm, yes. I test all releases on real (at least tdm24xx/tdm[84]xx, usually b410p too and sometimes on te205 cards as well) hardware. I also test the osclec integration (which currently breaks for 2.6.0 as well), I can't always test on zaphfc cards, but I do run into those from time to time and need the support. As per discussion between Tony and myself there are a few requirements that we would have before releasing a 2.6.0 ebuild: 1. parallel make (pain the backside). 2. oslec support (rediff of the tzafrir branch - hopefully easy) 3. forward-port all other patches from current patch set that is not yet committed upstream (most likely all of them). And then we'll look at jnet - but afaik there are no current jnet users (afaik there only ever was one, I chucked my junghauns card after it gave me way too much grief) and they haven't yet released an update (that we're aware of). If you're having problems with current ebuild releases, please do feel free to file bugs for them, or if you'd prefer come and discuss the issue with us in #gentoo-voip on freenode first (the issue you mention would be preferable to log upstream first and then just provide a link here).
(In reply to comment #8) > 2. oslec support (rediff of the tzafrir branch - hopefully easy) > 3. forward-port all other patches from current patch set that is not yet > committed upstream (most likely all of them). 2) Why not using the oslec implementation from actual kernel? This is still in the staging area indeed...where're the differences between these versions? I just replaced oslec from our patchset with these from kernel-3.2 and dahdi-2.6 compiles fine. 3)Have a look at 'http://git.tzafrir.org.il/?p=dahdi-extra.git;a=tree' in the subdirs of /drivers/dahdi/ opvxa1200.c and wcopenpci.c are rather old and seems to need some fixing for dahdi-2.6 For zaphfc please have a look at 'http://sourceforge.net/projects/dahdi-hfcs/?source=directory' which Stefan has found. I replaced our patchset with these sources and dahdi-2.6 compiles fine, too. So my thoughts are: - set dahdi-2.6 ebuild on hold until tzafrir has done some fixing - remove support for opvxa1200 and wcopenpci for now until fixed
Oliver, you want: http://gitorious.org/dahdi-extra/dahdi-linux-extra Not the tzafrir.org.il which is about a year out of date.
(In reply to comment #10) > Oliver, you want: > http://gitorious.org/dahdi-extra/dahdi-linux-extra > > Not the tzafrir.org.il which is about a year out of date. *gosh* Thanks for this hint. Adopted it and compiles clean and smoothly - but *without* parallel makin' :( So in my opinion still missing things are: - parallel make - junghanns drivers compatible to dahdi-2.6
Agreed. Losing the junghanns.net drivers would be unfortunate, but not the end of the world.
Well *fingers crossed* I may have fixed my dahdi-2.5 voice problems. Looking through my dmesg bootup log, I noticed a warning about needing to enable IOMMU in BIOS to save 64M ram, which I've always ignored. So I decided to follow directions and go into BIOS settings on my Supermicro H8SGL motherboard. And so I enabled IOMMU plus ACPI-v3 and some other changes (should never make more than 1 change at a time to BIOS!) and when I rebooted my TDM400P cards no longer worked at all. Eventually I discovered the culprit was enabling IOMMU -- so I disabled it as before and I then got dahdi working but with the same choppy voice as before. But I thought maybe some kernel config option dealing with AGP/DRM/IOMMU might be causing the problems. So I copied an old .config from an earlier kernel and re-did "make oldconfig", disabling AGP/drm support + most ACPI modules. I did a 'diff -y --suppress-common-lines oldconfig newconfig', which shows I got tired at 3am and probably hit CR too many times during the make and so probably built more uncessary modules than I would have liked, but things seem better today. I'm going to make a backup of this kernel config, then clean it up disabling unnecessary HID, ethernet drivers and such. Seems like when the kernel renames CONFIG option like the new ethernet option, 'make oldconfig' sets 'Y' as the default for most modules.
Created attachment 302493 [details] ebuild for dahdi-2.6.0 First try of an (so what) proper ebuild for dahdi-2.6 . Junghanns drivers are left out for now until proper version. The (new) opvxd115 driver seems not to be parallel-make-safe so I changed to 'emake -j1' for now. Otherwise this ebuild compiles smooth and clean. Not tested on any hardware yet.
Created attachment 302495 [details] new patchset for dahdi-2.6
Created attachment 302583 [details] dahdi-2.6.0.ebuild Changes: * Removed explicit -j1 (We don't want this). * Fixed firmware download paths * Do not download jnet if we're not going to use it. This is NOT production ready. Firstly - parallel builds STILL fails. Secondly - that non-digium-hardware patch most likely still contains a bug picked up by myself + tzafrir this morning (zaphfc hardware).
Created attachment 310003 [details, diff] 01-udevinfo-fallback-not-primary.diff
Created attachment 310005 [details, diff] 02-dialout-group-not-asterisk.diff
Created attachment 310007 [details, diff] 03-gcc44-compat-disable-debug.diff
Created attachment 310009 [details, diff] 04-no-depmod.diff
Created attachment 310011 [details, diff] 05-parallel-make.diff
Created attachment 310013 [details, diff] 06-udev-directory.diff
Created attachment 310015 [details, diff] 07-grsecurity-no-constify.diff
Created attachment 310017 [details, diff] 98-non-digium-hardware-and-oslec.diff
Created attachment 310019 [details, diff] 99-oct612x-split.diff
Created attachment 310021 [details] dahdi-2.6.1.ebuild
This shows the "recompile during install stage" problem on my system. I will attach a build log.
Created attachment 310023 [details] build.log
(In reply to comment #24) > Created attachment 310017 [details, diff] [details, diff] > 98-non-digium-hardware-and-oslec.diff Are there any reasons why oslec is still commented in (line #46 and #51) patched drivers/dahdi/Kbuild?
(In reply to comment #29) > Are there any reasons why oslec is still commented in (line #46 and #51) > patched drivers/dahdi/Kbuild? Good catch. Quick (and too quick, form the sound of it) rediffs for patch rejects, please provide updated diffs (*not* a tarball) and I will mark those as obsoleting my patches. Any luck with eliminating the unwanted full rebuild in the install stage?
(In reply to comment #30) > (In reply to comment #29) > > Are there any reasons why oslec is still commented in (line #46 and #51) > > patched drivers/dahdi/Kbuild? > > Good catch. Quick (and too quick, form the sound of it) rediffs for patch > rejects, please provide updated diffs (*not* a tarball) and I will mark > those as obsoleting my patches. > Any luck with eliminating the unwanted full rebuild in the install stage? Hold it, I was still testing on dahdi-2.6.0 in my horniness :) Just expanded, patched und diff'ed the Kbuilds from 2.6.1 and found out that Digium themselves set dahdi_echocan_oslec and echo (if patched with staging/echo)! So no oslec patching needed anymore by us. Will now cont. and report with testing/compiling.
(In reply to comment #31) > So no oslec patching needed anymore by us. Erm, I meant "no oslec patching needed anymore in Kbuild by us". Sorry for any unnecessary noises.
+*dahdi-2.6.1 (25 Apr 2012) + + 25 Apr 2012; Tony Vroon <chainsaw@gentoo.org> +dahdi-2.6.1.ebuild: + First attempt at packaging the 2.6 branch of DAHDI. Would not have been + possible without the assistance of Oliver Jaksch, Jaco Kroon & Felix Tiede. + Closes bug #403023. For the avoidance of doubt, the names are in alphabetical order. Many thanks to everyone involved for, among other things, taming build systems, rediffing patches and negotiating with hardware providers.
