Created attachment 365460 [details] dahdi-2.8.0.ebuild Digium released dahdi-2.8.0 with some bugfixes and improvements. Things I've done: (removed) 01-udevinfo-fallback-not-primary.diff (removed) 02-dialout-group-not-asterisk.diff (rediffed) 03-no-depmod.diff (rediffed) 04-parallel-make.diff (removed) 05-udev-directory.diff (rediffed) 06-grsecurity-no-constify.diff (added, closes #461780 and maybe #493206) 90-te_nt_override.240b.diff Compiles fine on x86. No further check done yet. Will run some tests, especially with a BN8S0 (concerning to '90-te_nt_override.240b.diff'), next weeks (too many holidays are upcoming).
Created attachment 365462 [details] gentoo-dahdi-patchset.tar.bz2
Comment on attachment 365460 [details] dahdi-2.8.0.ebuild --- dahdi-2.7.0.1.ebuild 2013-09-23 18:18:15.000000000 +0200 +++ - 2013-12-16 13:18:35.322965863 +0100 @@ -24,7 +24,7 @@ http://downloads.digium.com/pub/telephony/firmware/releases/dahdi-fw-te133-6f0017.tar.gz http://downloads.digium.com/pub/telephony/firmware/releases/dahdi-fw-te134-6f0017.tar.gz http://downloads.digium.com/pub/telephony/firmware/releases/dahdi-fw-te820-1.76.tar.gz -mirror://gentoo/gentoo-dahdi-patchset-1.1.6.tar.bz2 +#mirror://gentoo/gentoo-dahdi-patchset-1.1.6.tar.bz2 http://www.junghanns.net/downloads/jnet-dahdi-drivers-${JNET}.tar.gz" LICENSE="LGPL-2.1" @@ -37,7 +37,8 @@ RDEPEND="" EPATCH_SUFFIX="diff" -PATCHES=( "${WORKDIR}/dahdi-patchset" ) +#PATCHES=( "${WORKDIR}/dahdi-patchset" ) +PATCHES=( "${FILESDIR}" ) CONFIG_CHECK="MODULES CRC_CCITT"
(In reply to Oliver Jaksch from comment #0) > Digium released dahdi-2.8.0 with some bugfixes and improvements. Let's hope it's better than 2.7.0.1, which was an abortion. > Things I've done: > (removed) 01-udevinfo-fallback-not-primary.diff Neutral on this one. My system at least doesn't have udevinfo, only udevadm. The output generally gives the impression something is wrong: $ ver=`udevinfo -V | cut -f3 -d" "` bash: udevinfo: command not found So at a minimum that should get a 2>/dev/null in there, my vote goes towards keeping the patch since I'm betting the majority of Gentoo users would have udevadm (newer) rather than udevinfo (older). > (removed) 02-dialout-group-not-asterisk.diff Definite NACK. This behaviour shouldn't change. I don't mind the primary group, but I for one was someone that used the device nodes from DAHDI for a purpose *other* than asterisk. > (rediffed) 03-no-depmod.diff > (rediffed) 04-parallel-make.diff Neutral. Only difference seems to be the filename path in the patch headers and some relatively minor line-number offsets, and since we apply with -p1 anyway this makes no difference. The line numbers shouldn't affect patch at the sizes of these offsets. > (removed) 05-udev-directory.diff NACK. And we can't even override this one from emake CLI in the ebuild itself due to use of :=. Gentoo wants udev rules in /lib/udev/rules.d, not /etc/udev/rules.d. Need to keep this. > (rediffed) 06-grsecurity-no-constify.diff See above. > (added, closes #461780 and maybe #493206) 90-te_nt_override.240b.diff #461780 is a version bump to 2.6.2 of DAHDI, wrong reference. 493206 is a stabilization request for 2.7.0.1 - please find the appropriate references. Patch itself looks OK but I honestly don't like it: 1. The bitmask handling differs between the old mechanism and the newly added code - this should be made more consistent (easier to parse). 2. There should be no need for this patch unless the old behaviour is buggy to begin with. The Digium card is the exception here, and all the rest has different handling - if there is other cards that behave like B410P then the old code should be extended to accommodate those cards and to deal with them correctly out of the box - instead of depending on the end-user to specify some arbitrary bit-mask that may not be 0xFFFF (and 16 BRI channels in a single box is not unthinkable). Having said that the te_nt_override parameter at 0xFFFF leaves the default behaviour in place. I don't see how this patch actually provides any functionality that we should have that we don't - keeping in mind that overriding the NT/TE mode merely changes what the software THINKS is on that port - the jumpers also sets some impedance matches which is an electrical property which we cannot set from software. The software should in this case track the hardware. Chainsaw - inclusion of the patch gives some new ability to override hardware detected settings (eg, I can force the card into TE mode in spite of the jumpers of the card being set to NT). In my personal opinion this is rather dangerous, and without proper motivation I would personally not include this, but rather use the patch set exactly as it was for 2.7.0.1. My vote on the patch goes towards NACK unless it can be motivated properly *and* the 16-channel issue sorted out (An int on larger systems is 32 or even 64 bits big, so ~0UL would be more appropriate as sentinel IMHO). > Compiles fine on x86. No further check done yet. Will run some tests, > especially with a BN8S0 (concerning to '90-te_nt_override.240b.diff'), next > weeks (too many holidays are upcoming). The attached .tar.bz2 actually renames the internal folder from the current stable's dahdi-patchset to gentoo-dahdi-patchset.
I was being an idiot and need to revisit my responses. (In reply to Jaco Kroon from comment #3) > > Things I've done: > > (removed) 01-udevinfo-fallback-not-primary.diff ACK. dahdi-2.8.0 no longer contains udev rules. Patch needs to be migrated to dahdi-tools. > > (removed) 02-dialout-group-not-asterisk.diff ACK. See above. > > (rediffed) 03-no-depmod.diff > > (rediffed) 04-parallel-make.diff > > Neutral. Only difference seems to be the filename path in the patch headers > and some relatively minor line-number offsets, and since we apply with -p1 > anyway this makes no difference. The line numbers shouldn't affect patch at > the sizes of these offsets. No further comment but since we need to remove patches anyway we can just as well, ACK. > > (removed) 05-udev-directory.diff ACK. See above. New patch is already on bug #494442 albeit incomplete when considering the patches to be removed here. > > (rediffed) 06-grsecurity-no-constify.diff > > See above. ACK. See above. > > (added, closes #461780 and maybe #493206) 90-te_nt_override.240b.diff > > #461780 is a version bump to 2.6.2 of DAHDI, wrong reference. 493206 is a > stabilization request for 2.7.0.1 - please find the appropriate references. > > Patch itself looks OK but I honestly don't like it: > > 1. The bitmask handling differs between the old mechanism and the newly > added code - this should be made more consistent (easier to parse). > 2. There should be no need for this patch unless the old behaviour is buggy > to begin with. The Digium card is the exception here, and all the rest has > different handling - if there is other cards that behave like B410P then the > old code should be extended to accommodate those cards and to deal with them > correctly out of the box - instead of depending on the end-user to specify > some arbitrary bit-mask that may not be 0xFFFF (and 16 BRI channels in a > single box is not unthinkable). > > Having said that the te_nt_override parameter at 0xFFFF leaves the default > behaviour in place. I don't see how this patch actually provides any > functionality that we should have that we don't - keeping in mind that > overriding the NT/TE mode merely changes what the software THINKS is on that > port - the jumpers also sets some impedance matches which is an electrical > property which we cannot set from software. The software should in this > case track the hardware. > > Chainsaw - inclusion of the patch gives some new ability to override > hardware detected settings (eg, I can force the card into TE mode in spite > of the jumpers of the card being set to NT). In my personal opinion this is > rather dangerous, and without proper motivation I would personally not > include this, but rather use the patch set exactly as it was for 2.7.0.1. > My vote on the patch goes towards NACK unless it can be motivated properly > *and* the 16-channel issue sorted out (An int on larger systems is 32 or > even 64 bits big, so ~0UL would be more appropriate as sentinel IMHO). No further comment. > The attached .tar.bz2 actually renames the internal folder from the current > stable's dahdi-patchset to gentoo-dahdi-patchset. This remains an issue.
Created attachment 366638 [details] gentoo-dahdi-patchset-1.1.7.tar.bz2 Patchset adjusted to reflect the comments by jkroon.
Created attachment 366640 [details] dahdi-2.8.0.1.ebuild And an ebuild file to use it, reflecting new firmware URLs etc.
Apparent parallel make failure that will need to be addressed before the above can be merged: /var/tmp/portage/net-misc/dahdi-2.8.0.1/work/dahdi-linux-2.8.0.1/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_interrupts.o: file not recognized: File truncated scripts/Makefile.build:444: recipe for target '/var/tmp/portage/net-misc/dahdi-2.8.0.1/work/dahdi-linux-2.8.0.1/drivers/dahdi/oct612x/oct612x.o' failed make[3]: *** [/var/tmp/portage/net-misc/dahdi-2.8.0.1/work/dahdi-linux-2.8.0.1/drivers/dahdi/oct612x/oct612x.o] Error 1 scripts/Makefile.build:455: recipe for target '/var/tmp/portage/net-misc/dahdi-2.8.0.1/work/dahdi-linux-2.8.0.1/drivers/dahdi/oct612x' failed make[2]: *** [/var/tmp/portage/net-misc/dahdi-2.8.0.1/work/dahdi-linux-2.8.0.1/drivers/dahdi/oct612x] Error 2 make[2]: *** Waiting for unfinished jobs....
Created attachment 366862 [details, diff] dahdi-2.8.0.1-oct612x-parallel.patch I actually suspect this one is a kernel-build-system bug, and I *think* the patch should fix it, only compile-tested once and it worked. Seems to make logical sense so I'm thinking it should be OK. Kernel typically do NOT use sub-folders for storing .o files in, so the kernel generally assumes that all .o files for a given .ko resides in the same sub-folder, which is a sensible assumption, however, oct612x devs doesn't think so. And I can see their point too.
Created attachment 366942 [details, diff] 98-non-digium-hardware-and-oslect.diff Ok, so I just got really lucky on the previous fix ... this one is the correct one. Exactly the same problem as previously for dahdi 2.6, except that in the meantime Digium took exactly my idea and committed a variant thereof into dahdi-linux. The problem is actually with our 98-non-digium-hardware-and-oslec.patch file, for which I'm uploading an udpated version. The change basically post-patches with this: diff -uNr dahdi-linux-2.8.0.1.ORIG/drivers/dahdi/opvxd115/Kbuild dahdi-linux-2.8.0.1/drivers/dahdi/opvxd115/Kbuild --- dahdi-linux-2.8.0.1.ORIG/drivers/dahdi/opvxd115/Kbuild 2014-01-04 10:42:05.822134173 +0200 +++ dahdi-linux-2.8.0.1/drivers/dahdi/opvxd115/Kbuild 2014-01-04 10:42:21.226134405 +0200 @@ -8,7 +8,7 @@ EXTRA_CFLAGS+=-DHOTPLUG_FIRMWARE endif -opvxd115-objs := base.o vpm450m.o $(shell $(src)/../oct612x/octasic-helper objects ../oct612x) +opvxd115-objs := base.o vpm450m.o DAHDI_KERNEL_H_NAME:=kernel.h DAHDI_KERNEL_H_PATH:=$(DAHDI_INCLUDE)/dahdi/$(DAHDI_KERNEL_H_NAME) But instead of adding this as a patch on top of the existing patch I've opted to rather just fix the patch itself.
+*dahdi-2.8.0.1 (04 Jan 2014) + + 04 Jan 2014; Tony Vroon <chainsaw@gentoo.org> +dahdi-2.8.0.1.ebuild: + Version bump, as requested by Oliver Jaksch in bug #494436. Initial rediff by + Oliver Jaksch, with some finishing touches by Jaco Kroon.
