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.