Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.1-1.2.6.15_1.1826.2.9_FC5.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.1-1.2.6.15_1.1826.2.9_FC5.src.rpm Description: Zaptel (telephony hardware) kernel modules.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.1-2.2.6.15_1.1826.2.10_FC5.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.1-2.2.6.15_1.1826.2.10_FC5.src.rpm Won't build SMP variant on x86_64 since x86_64 doesn't have a SMP variant.
(In reply to comment #1) > Updated Spec/SRPM: > > Spec Name or Url: > http://www.ocjtech.us/zaptel-kmod-1.2.1-2.2.6.15_1.1826.2.10_FC5.spec > SRPM Name or Url: > http://www.ocjtech.us/zaptel-kmod-1.2.1-2.2.6.15_1.1826.2.10_FC5.src.rpm > > Won't build SMP variant on x86_64 since x86_64 doesn't have a SMP variant. Are you sure? x86_64 smp kernels are definitely available: # rpm -q kernel-smp kernel-smp-2.6.14-1.1656_FC4.x86_64 and I verified that it does build the x86_64 smp variant with no errors.
(In reply to comment #2) > (In reply to comment #1) > > > > Won't build SMP variant on x86_64 since x86_64 doesn't have a SMP variant. > > Are you sure? FC5 does not have a separate kernel for UP & SMP x86_64 systems. The same kernel runs on both.
there is no smp x86_64 kernel in fc5 there should be a check for version and only enable smp variant on the targets that support it devel i386 has i586 and i686 up, i686 smp, i686 xen (one for hypervisor and one for client) x86_64 has just the one kernel ppc in devel has up , smp there is however a ppc64iseries and ppc64 kernel in the ppc tree fc4 i386 same as devel x86_64 has UP and SMP ppc same as devel fc3 i386 has i586 and i686 UP and SMP kernels x86_64 same as fc4 So there is alot of variants need to be taken into consideration
one thing I just picked up when building the module /home/dennis/redhat/BUILD/zaptel-kmod-1.2.1/up/zaptel-1.2.1/ztdummy.c:103:2: warning: #warning This module will not be usable since the kernel HZ setting is not 1000 ticks per second. the ztdummy module says it wont work. this is the one module most people will want to use. as its needed for conference room timing.
Jeffrey, you know that we're still considering switching to another, slightly modified proposal? One where you don't have to hard-code the kernel-variants in the spec-file (would avoid problems like the ones in comments #2 to #4 in the future) You should probably be a bit patient and wait for the final version of the kernel-module packaging standard.
(In reply to comment #6) > Jeffrey, you know that we're still considering switching to another, slightly > modified proposal? One where you don't have to hard-code the kernel-variants in > the spec-file (would avoid problems like the ones in comments #2 to #4 in the > future) > > You should probably be a bit patient and wait for the final version of the > kernel-module packaging standard. I'll keep updating my packages as the proposal evolves, but I really hope that something comes together soon. People have been waiting for a long time for Asterisk in Fedora Extras, and getting Zaptel approved is a necessary first step. I think that packaging the Zaptel modules will serve as a good test case for the kernel module proposal.
(In reply to comment #7) > > You should probably be a bit patient and wait for the final version of the > > kernel-module packaging standard. > > I'll keep updating my packages as the proposal evolves, Okay. That's your decision and might be a bit more work, but probably is a good idea in general because it helps testing that the proposal really works ;-) > but I really hope that something comes together soon. I think so
(In reply to comment #5) > one thing I just picked up when building the module > /home/dennis/redhat/BUILD/zaptel-kmod-1.2.1/up/zaptel-1.2.1/ztdummy.c:103:2: > warning: #warning This module will not be usable since the kernel HZ setting > is not 1000 ticks per second. > > the ztdummy module says it wont work. this is the one module most people > will want to use as its needed for conference room timing. Which kernel/arch is this with? I haven't run across this with my testing, but I've only tested with a small cross-section of systems. Unfortunately, this is the way that Digium built the system. Replacing the code in Asterisk that depends on Zaptel kernel modules for anything but accessing real Zaptel hardware is technically possible but that isn't something that Digium seems to think is a very high priority.
kernel 2.6.15_1.1826.2.9_FC5 on x86_64
I know this isn't strictly related to this package, but has anyone got the kmod_package() macro to work on rhel4 ? It just complains about it being empty
(In reply to comment #7) > I'll keep updating my packages as the proposal evolves, but I really hope that > something comes together soon. Jeffrey, feel free to update to something that is similar to the packages referred in this mail: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00873.html This is the direction we'll probaly take (but don't delete the current versions -- just in case) Please tell me about any problems you hit with this new scheme (private mail or directly to the list please). tia
(In reply to comment #11) > I know this isn't strictly related to this package, but has anyone got the > kmod_package() macro to work on rhel4 ? See comment 12. Additionally, not really tested, but the whole current kernel module packaging proposal doesn't work as-is on RHEL4 because 1) its non-UP kernel-*-devel packages do not provide kernel-devel-$arch = $kver$kvariant, and 2) they lack the $uname_r-$arch formatted symlink in /usr/src/kernels. But I think the proposal can be fine tuned at least to work better in it without losing anything though. Will look into it and post results to extras list, stay tuned.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.2-1.2.6.15_1.1860_FC5.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.2-1.2.6.15_1.1860_FC5.src.rpm * Wed Jan 18 2006 Jeffrey C. Ollie <jeff> - 1.2.2-1 - Update to 1.2.2. - Add a couple of patches for 2.6.16-rc1 compatibility. - Change to fedora-kmodhelper-style package.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.2-2.2.6.15_1.1871_FC5.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.2-2.2.6.15_1.1871_FC5.src.rpm * Tue Jan 24 2006 Jeffrey C. Ollie <jeff> - 1.2.2-2 - Use standard kernel install instead of doing it manually. - Don't let the makefile choose optimization flags because it gets it wrong when building i686 packages in mock on an x86_64 system.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.3-1.2.6.15_1.1881_FC5.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.3-1.2.6.15_1.1881_FC5.src.rpm * Mon Jan 30 2006 Jeffrey C. Ollie <jeff> - 1.2.3-1 - Update to 1.2.3. - Update to latest kernel spec template. - Remove upstreamed ztdummy_rtc patch.
Regarding comment #9 there is a patch I have used and tested courtesy of dwmw2. It works fine for me. I'll attach it
Created attachment 124599 [details] Zaptel kernel 1000Hz -> 250Hz patch This patch makes ztdummy work with FC kernels that use 250Hz instead of the 1000Hz that the original ztdummy expects.
I've modified the patch a little bit so that it will work on any kernel whether it's set for 1000Hz or 250Hz. That way I don't have to add a bunch of %ifarch sections to the spec file. I've attached the patch but I haven't tested it out yet.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.4-1.2.6.15_1.1939_FC5.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.4-1.2.6.15_1.1939_FC5.src.rpm %changelog * Wed Feb 15 2006 Jeffrey C. Ollie <jeff> - 1.2.4-1 - Update to 1.2.4.
xpp/xpp_cap.c probably need a patch too /usr/src/redhat/BUILD/zaptel-kmod-1.2.4/_kmod_build_/xpp/xpp_zap.c:365:2: warning: #warning This module will not be usable since the kernel HZ setting is not 1000 ticks per second.
(In reply to comment #20) > Updated Spec/SRPM: > > Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.4-1.2.6.15_1.1939_FC5.spec > SRPM Name or Url: > http://www.ocjtech.us/zaptel-kmod-1.2.4-1.2.6.15_1.1939_FC5.src.rpm > > %changelog > * Wed Feb 15 2006 Jeffrey C. Ollie <jeff> - 1.2.4-1 > - Update to 1.2.4. > the XPP-modules introduced in zaptel-1.2.4 won't build on x86_64, so they should be disabled until a upstream fix exists.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.4-2.2.6.15_1.2054_FC5.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.4-2.2.6.15_1.2054_FC5.src.rpm * Wed Mar 15 2006 Jeffrey C. Ollie <jeff> - 1.2.4-2 - Disable building of XPP modules since the don't build on x86_64.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.5-1.2.6.16_1.2088_FC6.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.5-1.2.6.16_1.2088_FC6.spec * Mon Mar 27 2006 Jeffrey C. Ollie <jeff> - 1.2.5-1 - Update to 1.2.5
zaptel-ztdummy-250hz.diff.txt:37 +if ((HZ != 1000) || (HZ != 250)) { + printk("ztdummy: This module requires the kernel HZ setting to be 1000 or 250 ticks per second\n"); return -ENODEV; There is a logic problem with that. It should either be - !((HZ = 1000) || (HZ = 250)) or (HZ != 1000) && (HZ != 250) Otherwise, without the RTC, the ztdummy module will not load as it will act exactly the opposite of what it was intended to.
Sorry, a correction. The condition will fail for any value of HZ and prevent the module from being loaded.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.5-3.2.6.16_1.2157_FC6.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.5-1.2.5-3.2.6.16_1.2157_FC6.src.rpm %changelog * Thu Apr 27 2006 Jeffrey C. Ollie <jeff> - 1.2.5-3 - Update zaptel-ztdummy-250hz.diff.txt with fixes from Andy Kwong
FYI, there's a new kmodtool (0.10.7) available in CVS, for example in lirc-kmod devel, which should make yum behave better with the resulting packages. http://cvs.fedora.redhat.com/viewcvs/devel/lirc-kmod/?root=extras By the way, the SRPM url in comment 27 has noe "-1.2.5" too many.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.5-4.2.6.16_1.2157_FC6.spec SRPM Name or Url: http://www.ocjtech.us/zaptel-kmod-1.2.5-4.2.6.16_1.2157_FC6.src.rpm %changelog * Thu Apr 27 2006 Jeffrey C. Ollie <jeff> - 1.2.5-4 - Updated kmodtool to 0.10.7.
Am I missing something? There is no %files section in the spec so I get an "Installed (but unpackaged) file(s) found:" error. Does the updated kmodtool create the %files section? (I'm new to the Extras packaging process). I'm using FC5 with with fedora-kmodhelper from fedora-rpmdevtools 1.5-1.fc5
(In reply to comment #30) > Am I missing something? There is no %files section in the spec so I get an > "Installed (but unpackaged) file(s) found:" error. Does the updated kmodtool > create the %files section? (I'm new to the Extras packaging process). > > I'm using FC5 with with fedora-kmodhelper from fedora-rpmdevtools 1.5-1.fc5 The %files section is generated by the kmodtool. The spec should be using the kmodtool script that is in the SRPM. I just tested rebuilding the SRPM on FC5 with kernel 2.6.16-1.2111_FC5 and the build completed just fine. There's a new version of zaptel due within a few days so I'll be updating the SRPM with the new version. At that time I'll make sure that the spec conforms to the latest revison of the kernel module guidelines.
Yep ... I'm dumb. It built just fine without me mucking around with the spec :) I was trying to use the fedora-kmodhelper instead. Thanks.
So, is the kernel module setup finalized in fedora extras now? Or still in flux? kmodtool 0.10.10 is out if you want to update to that. Should there be a kmodtool package that the other kernel packages BuildRequire: instead of including it in each kernel module package? I was able to build this package in mock, but only for the exact kernel on my development machine and with just it's exact arch. Can mock be used to build kmod packages? If so, how should it be called? I'd be happy to review this package provided the specs are finalized now... (or perhaps one of the folks that wrote the kmodtool would be interested in making this a test case...)
(In reply to comment #33) > So, is the kernel module setup finalized in fedora extras now? > Or still in flux? I suppose there will be changes required in the future (some approaching in the next days), but consider it ready to use. But maintainers of kmod-packages should be prepared that they need to adjust things now and them to some new developments. http://www.fedoraproject.org/wiki/Packaging/KernelModules > kmodtool 0.10.10 is out if you want to update to that. > Should there be a kmodtool package that the other kernel packages BuildRequire: > instead of including it in each kernel module package? No. It should either be in the SRPM or in redhat-rpm-macros. Shipping it stand-alone will lead to problems. > I was able to build this package in mock, but only for the exact kernel on my > development machine and with just it's exact arch. Then there is probalby something wrong in the spec. > Can mock be used to build > kmod packages? Yes. Luvna does it already for some weeks. >If so, how should it be called? No special handling should be needed. > I'd be happy to review this package provided the specs are finalized now... http://www.fedoraproject.org/wiki/Packaging/KernelModules > (or perhaps one of the folks that wrote the kmodtool would be interested in > making this a test case...) lirc-kmod and thinkpad-kmod should show how it's done properly.
Adding back in the last comments from the bugzilla crash: ------- Additional Comments From kevin 2006-06-08 23:18 EST ------- ok. I'd like to move this forward some... Using the spec/src.rpm from http://repo.ocjtech.us/asterisk-1.2/fedora/5/SRPMS/ (refered to from the asterisk review), and the "kernel module package" section in http://www.fedoraproject.org/wiki/Packaging/KernelModules. Name/URL and License are all known from your spec, but the guidelines also ask: "A publishable explanation from the author(s) why the module is not merged with the mainline kernel yet and when it's planed to get merged. You of course can ask the author to explain it directly in the bug report." Can you get that information from upstream? Also from that page: "All kernel module packages should use the template as a base. Reviewers of kernel modules should diff the proposed kernel module packages against the template. Only the names and the way the modules itself are build should differ. There shouldn't be other differences without a good reason." It's unclear what template should be diffed against there. kmodtool (the latest version is used by this spec) and thus generates the spec additions exactly as required. Is there a default template for the spec file to be used? If so where? I did diff against the thinkpad-kmod, but there is a good deal of whitespace and other minor changes that make it difficult to see changes. (BTW, thinkpad-kmod has a typo in it's spec refering to lirc on line 8) ------- Additional Comments From jeff.ia.us 2006-06-09 00:51 EST ------- (In reply to comment #35) > ok. I'd like to move this forward some... Excellent! > Using the spec/src.rpm from http://repo.ocjtech.us/asterisk-1.2/fedora/5/SRPMS/ > (refered to from the asterisk review), and the "kernel module package" section in > http://www.fedoraproject.org/wiki/Packaging/KernelModules. > > Name/URL and License are all known from your spec, but the guidelines also ask: > > "A publishable explanation from the author(s) why the module is not merged with > the mainline kernel yet and when it's planed to get merged. You of course can > ask the author to explain it directly in the bug report." > > Can you get that information from upstream? I'll see if I can get some sort of statement from Digium, but it seems to be a combination of "we don't want to go to the bother" and "we don't want to be at the mercy of the kernel developers". The zaptel modules work on both 2.4 and 2.6 kernels so there's a lot of compatibility code. Many of the newer features of 2.6 aren't taken advantage of. I'm sure that it would take a lot of work to cut out the 2.4 compatibility code, rewrite to take more advantage of 2.6 and to get something that fits the kernel style guidelines. I'd also bet that the majority of serious asterisk users aren't running asterisk on the latest & greatest kernel. In fact there are quite a few using 2.4. Yet they all need bug fixes and new features from the latest zaptel modules so there will likely always be a need to have a standalone package that can compile against older kernels. Since you need a standalone package anyway, why go to the extra work of getting the modules into the mainline kernel? Anyway, that's the read I get from the upstream developers. > Also from that page: > "All kernel module packages should use the template as a base. Reviewers of > kernel modules should diff the proposed kernel module packages against the > template. Only the names and the way the modules itself are build should differ. > There shouldn't be other differences without a good reason." > > It's unclear what template should be diffed against there. kmodtool (the latest > version is used by this spec) and thus generates the spec additions exactly as > required. Is there a default template for the spec file to be used? If so where? > I did diff against the thinkpad-kmod, but there is a good deal of whitespace and > other minor changes that make it difficult to see changes. > > (BTW, thinkpad-kmod has a typo in it's spec refering to lirc on line 8) As fas as I can tell there isn't an official template yet. I've been working from the thinkpad-kmod and the lirc-kmod packages. ------- Additional Comments From jeff.ia.us 2006-06-09 00:56 EST ------- I've also been seeing the following errors when trying to build i386 packages on a x86_64 host in mock: + make -C /usr/src/kernels/2.6.16-1.2122_FC5-i686 SUBDIRS=/builddir/build/BUILD/zaptel-kmod-1.2.6/_kmod_build_ modules make: Entering directory `/usr/src/kernels/2.6.16-1.2122_FC5-i686' CC [M] /builddir/build/BUILD/zaptel-kmod-1.2.6/_kmod_build_/zaptel.o /builddir/build/BUILD/zaptel-kmod-1.2.6/_kmod_build_/zaptel.c:1: error: code model 'kernel' not supported in the 32 bit mode make[1]: *** [/builddir/build/BUILD/zaptel-kmod-1.2.6/_kmod_build_/zaptel.o] Error 1 make: *** [_module_/builddir/build/BUILD/zaptel-kmod-1.2.6/_kmod_build_] Error 2make: Leaving directory `/usr/src/kernels/2.6.16-1.2122_FC5-i686' Is there something I'm doing wrong? Building x86_64 packages on a x86_64 box works fine, as well as building i386 packages on an i386 box. ------- Additional Comments From fedora 2006-06-09 01:18 EST ------- (In reply to comment #37) > I've also been seeing the following errors when trying to build i386 packages on > a x86_64 host in mock: use "setarch i686 mock ..." to build ------- Additional Comments From kevin 2006-06-09 01:42 EST ------- I seem to get a build failure on one of the patches: + pushd zaptel-1.2.6 ~/build/BUILD/zaptel-kmod-1.2.6/zaptel-1.2.6 ~/build/BUILD/zaptel-kmod-1.2.6 + patch -p0 patching file zconfig.h + patch -p0 patching file Makefile Hunk #1 FAILED at 22. 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej error: Bad exit status from /var/tmp/rpm-tmp.22247 (%prep) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.22247 (%prep) Can you put up the latest spec and src.rpm that you are using thats building cleanly? ------- Additional Comments From jeff.ia.us 2006-06-09 09:46 EST ------- (In reply to comment #38) > (In reply to comment #37) > > I've also been seeing the following errors when trying to build i386 packages on > > a x86_64 host in mock: > > use "setarch i686 mock ..." to build Thanks! That works... ------- Additional Comments From jeff.ia.us 2006-06-09 10:39 EST ------- (In reply to comment #39) > > Can you put up the latest spec and src.rpm that you are using thats building > cleanly? Those source rpms were built using mock, so they should be building cleanly. Nevertheless I've pushed out new source RPMs. The URL is: http://repo.ocjtech.us/asterisk-1.2/fedora/5/SRPMS/ ------- Additional Comments From rmo 2006-06-12 14:45 EST ------- I'm getting symbol errors both when trying to build kmod-zaptel on fc5.x86_64 and while installing pre build packages from repo.ocjtech.us [root@homer asterisk]# rpm -ivh kmod-zaptel-1.2.6-5.2.6.16_1.2133_FC5.x86_64.rpm Preparing... ########################################### [100%] 1:kmod-zaptel ########################################### [100%] WARNING: /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/pciradio.ko needs unknown symbol __stack_chk_fail WARNING: /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/wct4xxp.ko needs unknown symbol __stack_chk_fail WARNING: /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/wcusb.ko needs unknown symbol __stack_chk_fail WARNING: /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/wctdm24xxp.ko needs unknown symbol __stack_chk_fail WARNING: /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/ztd-eth.ko needs unknown symbol __stack_chk_fail WARNING: /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/wctdm.ko needs unknown symbol __stack_chk_fail WARNING: /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/ztdynamic.ko needs unknown symbol __stack_chk_fail WARNING: /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/wcte11xp.ko needs unknown symbol __stack_chk_fail WARNING: /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/zaptel.ko needs unknown symbol __stack_chk_fail Same error when building the packages my self ------- Additional Comments From tjb 2006-06-12 15:17 EST ------- Me too. [tjb@gile tjb]# modprobe zaptel FATAL: Error inserting zaptel (/lib/modules/2.6.16-1.2133_FC5smp/extra/zaptel/zaptel.ko): Unknown symbol in module, or unknown parameter (see dmesg) [tjb@gile tjb]# ------- Additional Comments From jeff.ia.us 2006-06-13 08:44 EST ------- The __stack_chk_fail comes from compiling modules with -fstack-protector, which they obviously shouldn't. Did the 2.6.16-1.2122_FC5 modules work for you?
Yes, the new packages loads fine
ok, finally found some time to reboot my main asterisk box to the latest fc5 kernel so I could try this out. Everythings working fine with your: asterisk-zaptel-1.2.9.1-1.fc5 asterisk-zaptel-1.2.9.1-1.fc5 asterisk-sounds-default-1.2.9.1-1.fc5 asterisk-1.2.9.1-1.fc5 zaptel-1.2.6-3.fc5 kmod-zaptel-smp-1.2.6-6.2.6.16_1.2133_FC5 So, time to start in on some reviews. :) OK - Package name OK - Spec file matches base package name. OK - Meets Packaging Guidelines. OK - License (GPL) OK - License field in spec matches N/A - License file included in package OK - Spec in American English OK - Spec is legible. OK - Sources match upstream md5sum: c6058b74f43ae12a29e486cf1e919562 zaptel-1.2.6.tar.gz c6058b74f43ae12a29e486cf1e919562 zaptel-1.2.6.tar.gz.1 OK - Package compiles and builds on at least one arch. N/A - Package needs ExcludeArch OK - BuildRequires correct N/A - Spec handles locales/find_lang N/A - Spec has needed ldconfig in post and postun N/A - Package is relocatable and has a reason to be. OK - Package owns all the directories it creates. OK - Package has no duplicate files in %files. OK - Package has %defattr and permissions on files is good. OK - Package has a correct %clean section. OK - Spec has consistant macro usage. OK - Package is code or permissible content. N/A - -doc subpackage needed/used. N/A - Packages %doc files don't affect runtime. N/A - Headers/static libs in -devel subpackage. N/A - .pc files in -devel subpackage. N/A - .so files in -devel subpackage. N/A - -devel package Requires: %{name} = %{version}-%{release} N/A - .la files are removed. N/A - Package is a GUI app and has a .desktop file OK - Package doesn't own any directories other packages own. See below - No rpmlint output. Issues: 1. Still need the "A publishable explanation from the author(s) why the module is not merged with the mainline kernel yet and when it's planed to get merged. You of course can ask the author to explain it directly in the bug report." and approval from FESCo at the next meeting. 2. Fair pile of rpmlint output, most of which can be ignored I think: This would need to be fixed in kmodtool: W: kmod-zaptel summary-not-capitalized zaptel kernel module(s) W: kmod-zaptel unstripped-binary-or-object /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/wctdm.ko (repeats for each .ko in each subpackage.) I think this one is due to the name of the package vs the postin... the scriptlet has the right kernel name, the package has a extra _ in place of a - E: kmod-zaptel postin-with-wrong-depmod /lib/modules/2.6.16-1.2133_FC5/extra/zaptel/zaptel.ko (repeats for each .ko in each subpackage.) Can be ignored: W: kmod-zaptel no-documentation If you are not applying these, perhaps they should be dropped: W: zaptel-kmod patch-not-applied Patch0: zaptel-config.patch W: zaptel-kmod patch-not-applied Patch2: zaptel-optflags.patch 3. "Reviewers of kernel modules should diff the proposed kernel module packages against the template. Only the names and the way the modules itself are build should differ. There shouldn't be other differences without a good reason." I can't seem to get the current template from the wiki. The link seems to be: http://fedoraproject.org/wiki/Packaging/KernelModules?action=AttachFile&do=get&target=kmod-template.spec which doesn't work. 4. Finally: (Although we aren't at approval yet) "Everyone can review such a package, but after is was set to APPROVED by the reviewer a Fedora Extras Sponsor or someone experienced with kernel modules has to take a quick look at the package and post an additional approved notice before it is allowed to import the package into CVS." It would be great if one of the experenced kernel module folks could look over this once we reach approval.
Just a note that according to http://www.fedoraproject.org/wiki/Packaging/KernelModules reviews shouldn't even start until FESCo has a chance to approve the module, and before that happens, the statement from upstream is absolutely required. This package probably predates those guidelines, though. Anyway, any chance of getting that statement soon so I can sheperd this package through the committee?
Yeah, I don't think the guidelines were explicit before that the FESCo approval needed to be "*before* you start packaging a kernel module for Fedora Extras". In any case Jeff: Are you still interested in this package? It's been a month or so since any asterisk package updates on your site.
Yeah, I'm still interested in this package... hopefully we can get this thing through the process before Asterisk 1.4 has been released :). I've contacted someone at Digium to see if we can get a statement.
There are two primary reasons why we distribute Zaptel separately from the kernel source trees (and have not even offered them for inclusion in the source trees): 1) Zaptel supports both 2.4 and 2.6 kernel series, and many users will run 2.4 kernels but want access to driver fixes and drivers for new hardware as it arrives. Since the 2.4 kernel tree is essentially closed for new features, it's not likely we could get Zaptel merged into the 2.4 kernel tree, and thus we'd need to continue distributing it separately even if it was merged into the 2.6 tree (thus creating extra work for us to keep them in sync). As we move to supporting more the 2.6 kernel's new features in Zaptel, it's likely that we will discontinue support for the 2.4 kernel in the reasonably near feature, and at that time we can look at this issue again if it makes sense to do so. 2) Zaptel is available under both the GPLv2 license and also non-open-source commercial licenses negotiated with Digium. This means that contributions to Zaptel must be licensed for Digium to use them in non-open-source distributions, and thus we must strictly control the changes that get merged into the Zaptel source trees. If the Zaptel source was merged into the 2.6 kernel, there would be no method to continue this process (changes merged by other kernel developers would be made directly in the 2.6 tree, bypassing our licensing process), and the 2.6 tree version would begin to diverge from our dual-licensed version, which is not a situation we wish to be the case. I'm happy to provide any additional information that is needed here; we'd like to see Asterisk and Zaptel in Fedora Extras as well, so we'll do anything that's within reason to help achieve that goal :-)
(In reply to comment #41) > There are two primary reasons why we distribute Zaptel separately from the > kernel source trees [...] Both reasons seem wrong to me (especially reason 2) and your strategy counter-productive for the open-source world in general and the kernel-development-process in special. I'll forward the request for inclusion of this kernel-module to FESCo for approval, but I will do my best to prevent that this module get's into Extras as long as the plans says "we don't want to get the driver merged upstream"
(In reply to comment #42) > I'll forward the request for inclusion of this kernel-module to FESCo for > approval, but I will do my best to prevent that this module get's into Extras as > long as the plans says "we don't want to get the driver merged upstream" Which you realize would mean that we can't get a fully functioning asterisk (for people with zaptel hardware, which includes me) in Extras until somebody forks the kernel module development. I agree that Digium's development model leaves a bit to be desired (who needs to change the license of the kernel module anyway, and is that even legal?), but the fact is that zaptel is GPL, so is this really the right place to draw the proverbial line in the sand?
(In reply to comment #43) > (In reply to comment #42) > Which you realize would mean [...] Yes, I realized that. But there are 3rd party Fedora {Core|Extras} add-on repos out there that have different requirements for kmods -- one could submitt it there. > I agree that Digium's development model leaves a bit to be desired (who needs to > change the license of the kernel module anyway, and is that even legal?), The dual-licensing is not the problem afaics and afaik the details. For me it's only the "we don't want it upstream" mentality. I think every module should be in the kernel (see also http://www.kroah.com/log/linux/ols_2006_keynote.html ) and kmod in Extras are an interim solution to fill the timeframe until they get upstream (and in an ideal world people would get their drivers merged into the kernel as soon as they basically work) . > but > the fact is that zaptel is GPL, so is this really the right place to draw the > proverbial line in the sand? Well, one kernel-developer is hightly respect thinks the line should be drawn even earlier -- see Bug 189400 comment 9
(In reply to comment #44) > > but > > the fact is that zaptel is GPL, so is this really the right place to draw the > > proverbial line in the sand? > > Well, one kernel-developer is hightly respect thinks the line should be drawn > even earlier -- see Bug 189400 comment 9 I would like to point out that the same person that made that comment actually _uses_ this module even. I consider myself a fairly practical person that isn't swayed by politics often. However, I agree with Thorsten for this particular module. The reasoning from upstream is simply ridiculous. One of the 3rd party repos would be a better candidate for this module.
BTW, did someone point Kevin P. Fleming from digium to this discussion? He seems not be CCed (and I don't want to CC him). Maybe he/digium change their mind when they hear that some of us don't want this module in Extras. He should probably also read the discussion on fedora-devel: https://www.redhat.com/archives/fedora-devel-list/2006-August/msg00119.html
(In reply to comment #46) > BTW, did someone point Kevin P. Fleming from digium to this discussion? He seems > not be CCed (and I don't want to CC him). Maybe he/digium change their mind when > they hear that some of us don't want this module in Extras. > > He should probably also read the discussion on fedora-devel: > https://www.redhat.com/archives/fedora-devel-list/2006-August/msg00119.html I'm the one that invited him to the discussion... I'll ask him to check out the followup discussion.
Any news from Digium yet? Thanks, Gavin.
While there isn't yet a hard rule against modules that don't plan upstream inclusion, there are a number of folks in FESCo that don't want to approve modules that don't plan upstream inclusion. Any word from Digium if they might change their minds on that point? (I will send an email to Kevin Fleming about this point)
(In reply to comment #49) > While there isn't yet a hard rule against modules that don't plan upstream > inclusion, there are a number of folks in FESCo that don't want to approve > modules that don't plan upstream inclusion. > > Any word from Digium if they might change their minds on that point? I haven't heard anything, but I haven't been asking either. I've had to put any work on Asterisk stuff to the side as things at work have gotten very busy lately.
I'll try to address your concerns, but understand that we fight this battle every day with people who don't agree with our dual licensing model (or dual licensing in general), so I don't expect to change your minds :-) In regards to the question about Zaptel being GPL and not being usable under other licenses, that is not true. There are parts of Zaptel that are most definitely not derivatives of the Linux kernel and we want to retain the ability to license those parts of Zaptel outside the GPL. Stating that 'Zaptel is GPL' is somewhat of a simplification, because in reality you mean that 'the Zaptel distributed by Digium via their web/FTP servers is GPL', but we have the ability to distribute it via other means as well. As far as the 2.4 kernel issue goes, we definitely do consider that to be a concern, because we have limited kernel developer resources and don't wish to spend their time duplicating efforts, and there is still rather a large population of users running Zaptel on 2.4 kernels (we have received bug reports as recently as this week regarding new drivers we have not building/installing on 2.4). However, that is secondary to the licensing issue in any case. I can tell you that it is highly unlikely that Digium would decide to change the licensing model for Zaptel just so that it can be incorporated into Fedora Extras. While I don't wish to start a flamewar, I do find it somewhat curious that Debian does package Zaptel and they generally seem to be even more restrictive regarding licensing that most other distributions are... but I understand that your concern here is not the licensing issue, but our non-interest in pushing the Zaptel drivers upstream into the mainline kernel. I've added myself to the CC list for this issue; I'm happy to answer your questions and try to provide any technical assistance required, but the licensing issues are what they are.
Licensing is not the issue at all, dual licensing is perfectly acceptable. The issue at hand is merging zaptel into Linus's tree.
Agreed with comment #52, and also seems to be the thoughts of (at least) serveral FESCo members... Kevin: Can you address the "non-interest in pushing the Zaptel drivers upstream into the mainline kernel." with any more detail? There are many good advantages to getting things merged upstream. Even if you have to still expend energy maintaining a 2.4 branch, having all the eyes reviewing/fixing your 2.6 code could still be a good win, IMHO...
I really don't know what else can be said. In spite of comments like 'dual licensing is acceptable', I don't think the other commenters are willing to see our position at all. I know that you don't have a problem with including a dual-licensed component into your distribution, and I also know that Linus et. al. don't have a problem including dual-licensed code into the kernel tree. Those are not our concern. What is our concern is that if Zaptel is merged into the main kernel tree, from that point forward anyone who wants to improve it can do so without contributing their changes to our version of Zaptel, which devalues our dual licensing of Zaptel completely. Obviously, it is not in our best interests to do that. Today, of course, people can easily produce their own distributions of Zaptel with non-contributed changes (and those distributions exist), but since they are not considered 'official' they are not the distributions that mainstream users will want to use. If Zaptel is in the Linus kernel tree, that becomes the defacto 'official' distribution, and there would be no incentive at all for anyone to contribute their changes to us for use in our commercially-licensed products. I fully understand that the many members of the open source community do not really care whether Digium continues to benefit from dual-licensing Zaptel or not, and they are welcome to that opinion. In fact, if people want to take our GPL distribution of Zaptel and submit it for inclusion into the kernel tree (and continue maintenance of it from that point forward) then obviously they can do that (barring any potential trademark infringement issues, which I am not in a position to comment on). I just don't see that Digium will ever decide that the best place for Zaptel to live is in the kernel tree, and the primary driver of that decision is our choice to keep it dual-licensed and desire for changes to be contributed back to us. The additional benefits of having many more developers reviewing/fixing thec code would most certainly be welcome, but they don't currently outweigh the value of maintaining the ability to commercially license the relevant parts of the code base.
(In reply to comment #54) > I know that you don't have a problem with including a dual-licensed component > into your distribution, and I also know that Linus et. al. don't have a problem > including dual-licensed code into the kernel tree. Those are not our concern. > > What is our concern is that if Zaptel is merged into the main kernel tree, from > that point forward anyone who wants to improve it can do so without contributing > their changes to our version of Zaptel, which devalues our dual licensing of > Zaptel completely. In practice, that doesn't happen. I maintain a large chunk of dual-licensed code in the kernel (JFFS2), and Linus doesn't _take_ updates from anyone other than me unless they're trivial oneliners and build fixes, which you really don't have to worry about. People _already_ have the option to take your version of Zaptel and 'improve' it without giving their changes back. If I were inclined to do that, the _first_ thing I'd do is submit my version to Linus and become the defacto maintainer of it. You'd probably do well to get there first.
I already commented that someone else could do this, that's no surprise to me :-) I did not really consider the option that Linus would let us still be the official maintainers of Zaptel-in-the-kernel and thus we'd be responsible for merging all patches that come through other channels (unless we fail to do that job adequately). Given that, I'll talk to our people here and start the process, since that would allow us to maintain our licensing control where we need to. However, given the current state of the code, I can guarantee that it won't get merged into the mainline kernel tree soon, as it does not currently meet kernel coding guidelines. We'll need to get a kernel driver person working on cleaning up the code and preparing it for submission.
Great news ! As long as it is planned for inclusion in the mainline kernel, I guess it qualifies to be packaged in Extras.
Excellent news. Thanks for following this discussion Kevin. I will bring this up at the next FESCo meeting.
(In reply to comment #56) > I already commented that someone else could do this, that's no surprise to me :-) > > I did not really consider the option that Linus would let us still be the > official maintainers of Zaptel-in-the-kernel and thus we'd be responsible for > merging all patches that come through other channels (unless we fail to do that > job adequately). That's basically the case, yes. Patches to well-maintained subsystems go through the maintainers. Linus even rejected a patch from me to a USB driver I comaintain a week or so ago, because it didn't go through the USB maintainer. There are no guarantees, of course -- but basically I don't think you have anything to worry about on that front. > Given that, I'll talk to our people here and start the process, > since that would allow us to maintain our licensing control where we need to. That's excellent news -- thanks. > However, given the current state of the code, I can guarantee that it won't get > merged into the mainline kernel tree soon, as it does not currently meet kernel > coding guidelines. Indeed; that's one of the major reasons we insist on code being upstream before we'll ship it. > We'll need to get a kernel driver person working on cleaning > up the code and preparing it for submission. Let me know if you need assistance on this front. I have a disclaimer on file, kernel hacking is what I do for fun after a hard day's work kernel hacking, and my manager just told me to chase up the process of getting Asterisk into Fedora... I still don't want a zaptel-kmod package, or indeed _any_ kmod package in Extras. If/when it's good enough to ship and it's queued for 2.6.20 inclusion, I'll probably just put it directly into the Fedora kernel. DaveJ approval permitting, of course.
I very much appreciate the offer of assistance... once we have worked through some internal discussions about whether this is something everyone is comfortable with or not I'll get back to you all. I really do want to move this direction now that I have had more time to consider it and talk to members of the community about it, but I need to ensure that the rest of the Digium team is behind it too.
FYI, in todays FESCo meeting, they decided to wait another week before approving/disapproving this package. Kevin: If you could provide a comment here that the rest of the Digium team is happy to move forward with upstream inclusion, that will help next weeks voting. ;)
Due to travel and other scheduling conflicts we won't even be able to have a discussion about this internally until around October 18th or so, so I can't give you any commitment until after that discussion occurs.
There's more work to be done after the agreement from Digium to merge it upstream -- we have to actually make the code _acceptable_ upstream. So next week would be massively inappropriate anyway. It's quite concerning to hear such a thing being said. When it's ready upstream, we can put it into the rawhide kernel. Only when that's done would it be sensible to even _consider_ doing a kmod package for it -- and even then we might as well just put it into a released erratum of the kernel package proper, if we really want to ship it.
Unless there are any objections posted in the next few days, I'm going to close this review request since it looks like the zaptel kernel modules will eventually become part of the base kernel package.
Without releasing the zaptel-kmod package, you're now in a situation where you have released the zaptel utilities and libs packages, but there is no supporting kernel module. Reading the thread above, it can easily take months for zaptel to be ready for and accepted in the kernel and end up in a Fedora kernel rpm. The zaptel packages are completely useless without the kernel module, since it's a hardware driver.
No, it's not at all useless -- if someone _has_ this hardware then they only need to build the modules to support it. They don't need to also build the libraries and rebuild Asterisk/OpenPBX with zaptel support. If we didn't include zaptel support, then our Asterisk and OpenPBX packages would be useless for anyone who wants to use Zaptel hardware. As it is, they're not useless for those people -- all that's required is to build and install the kernel part.
And it'll only take months if people sit back and wait for someone else to do the work...
I can't get the zaptel-kmod.spec to build in mock on Fedora Core 6. If use the following rpmbuild command to build outside of mock everything build fine: rpmbuild -ba SPECS/zaptel-kmod.spec --define 'kernel 2.6.18-1.2798.fc6' --define 'kvariants ""' --target i686 However, mock tries to rebuild the SRPM without the --define options and (I assume) rpmbuild throws: error: Package already exists: %package -n kmod-zaptel If I run the same command that mock is running to build the SRPM: rpmbuild -bs --target i686 --nodeps SPECS/zaptel-kmod.spec I receive the same error. Does anyone have an idea as to whether this error is a problem with the spec file, mock, rpmbuild or kmodtool? Here are my package versions: mock-0.6.8-4.fc6 rpm-build-4.4.2-32 rpmdevtools-5.3-1.fc6 kmodtool 0.10.11 Thanks, Andy.
There was a change in the kernel sometime after 2.6.17 that made zaptel not compile anymore. The bug was fixed in the Zaptel SVN but I don't think that the change has made its way into a released version. In any case, I'm not going to be producing new zaptel-kmod packages because the decision was made to get zaptel into the kernel package rather than as a separate RPM.
Thanks Jeff. I can build the zaptel-kmod package outside of mock just fine, so I think that this problem is with kmodtool or mock or I just don't know how to use mock correctly :) If some kind soul could talk a look at the errors above and point me in the right direction I would greatly appreciate it :) Thanks.
Oh, right, sorry... working on 3 hours of sleep right now... Mock does not add any --defines or anything like that for building kernel modules. You'll need to edit the spec file and manually add macro definitions like this: %define kernel 2.6.18-1.2798.fc6 %define kvariants ""
Unless you have Digium hardware, the right direction for now is probably OpenPBX. That's been fixed to use POSIX timers instead of relying on zaptel kernel code.
what happened to this ?
kmods were never very well acceped (and now they are totally banned). It'll be better for everyone concerned for Digium to get the zaptel kernel modules included in the vanilla kernel. If you really need the Zaptel kernel modules right now you'll need to install them from source or obtain RPM packages from another source. The Zaptel userspace library is a part of Fedora and be obtained from the usual sources.