Spec Name or Url: http://www.ocjtech.us/spandsp-0.0.3-0.1.pre4.spec
SRPM Name or Url: http://www.ocjtech.us/spandsp-0.0.3-0.1.pre4.src.rpm
SpanDSP is a library of DSP functions for telephony, in the 8000
sample per second world of E1s, T1s, and higher order PCM channels. It
contains low level functions, such as basic filters. It also contains
higher level functions, such as cadenced supervisory tone detection,
and a complete software FAX machine. The software has been designed to
avoid intellectual property issues, using mature techniques where all
relevant patents have expired. See the file DueDiligence for important
information about these intellectual property issues.
Oops... almost forgot. SpanDSP is a dependency for OpenPBX.org which I hope to
package once it stabilizes.
* HTML doc is packaged twice, leave in -devel only
* %prep : "%setup0 -q" should be "%setup -q"
* include the COPYING file
* What does Legal think of the DueDiligence file ?
Spec Name or Url: http://www.ocjtech.us/spandsp-0.0.3-0.2.pre4.spec
SRPM Name or Url: http://www.ocjtech.us/spandsp-0.0.3-0.2.pre4.src.rpm
As far as the DueDilligence file, I've asked in a number of places about the
implications of including SpanDSP in FE before and gotten generally positive
responses. I have not specifically gotten any opinions from RedHat Legal. What
is the process for requesting an opinion from Fedora Legal? Nothing obvious
turned up in a Google search or the Fedora wiki.
*Ping* Still waiting for information on how to get RedHat Legal to sign off on
FWIW, Debian carries spandsp. I'm searching for any trace of a discussion about
the legal status of spandsp on the debian lists.
I actually bothered to look at the IP issues when developing spandsp. Most
projects ignore them, and just hope they go away. Nobody seems to worry about
that. A due diligence file that addresses things and finds them to be OK worries
I could find no patents problems with anything except V.17. Other patents have
lond expired (e.g. one on V.29). I couldn't track down the exact patent IBM
claim on V.17. However, I think it relates to trellis coding, and I think it
should be mid 80s vintage. That means it should be OK outside the US, but might
need checking for the exact expiry date in the US.
Oops, a bit got chopped off my last comment.
Because of the uncertain status of V.17, it is not build by default. In fact,
right now it isn't even 100% reliable. It needs more work. A default build of
spandsp has no patent issues.
Aurelian... Can you take another look at this package? It's been sitting here
for a while now.
Sorry to get back so late.
Review for release 0.2.pre4:
* RPM name is OK
* Source spandsp-0.0.3pre4.tgz is the same as upstream
* Builds fine in mock
* rpmlint looks OK
* File list looks OK
Everything looks OK to me packaging-wise, but I'd like to test-run it if
possible. Is there a program linked to it I could try ?
No problemo... I understand fully about busy schedules...
The only real program that I have right now that uses spandsp is Asterisk
(#178922), which would take quite a bit to get set up just to test spandsp.
There is some test code included with spandsp but I haven't figured out the
magic incantation to get it the tests to compile.
Well, I wanted to try asterisk anyway. I guess it's the perfect occasion
The spec looks pretty good to me and compiles clean on centos 3. I'll test it
and your asterisk package soon(TM).
Spec Name or Url: http://www.ocjtech.us/spandsp-0.0.2-1.pre25.spec
SRPM Name or Url: http://www.ocjtech.us/spandsp-0.0.2-1.pre25.src.rpm
"Downgraded" to 0.0.2-based release because Asterisk does not seem to work with
0.0.3 (although it compiles, the RxFAX/TxFAX applications don't work).
What is the status of this package?
(In reply to comment #14)
> What is the status of this package?
It's in a bit of limbo... There's not much point to getting spandsp in Extras
unless Asterisk makes it in, and there's not much point for Asterisk in Fedora
Extras without the Zaptel kernel modules (you lose a lot of
important/interesting functionality in Asterisk without Zaptel). The Zaptel
modules are being held up due to disagreements about how to package them
properly (or even if they should be packaged at all).
I disagree with comment 15. There's plenty of point in having Asterisk even
without Zaptel -- and there's certainly no real need to delay packages on which
it depends, just because we're being slow in getting the Zaptel mess sorted out.
Updated to 0.0.2pre26 and accepted -- package at
Imported and built for development, FC-5 branch requested.
Hm, now can we update it to 0.0.3 again? If Asterisk doesn't work with that,
then we'll have to fix Asterisk.
configure: error: SpanDSP does not appear to be new enough. You must have
version 0.0.3pre23 or newer to compile OpenPBX.org.
Package Change Request
Package Name: spandsp
New Branches: EL-5
Updated EPEL Owners: jcollie
Needed to build Asterisk package on EL-5.
spandsp-0.0.6-0.10.pre21.el7 has been submitted as an update for Fedora EPEL 7.
spandsp-0.0.6-0.10.pre21.el7 has been pushed to the Fedora EPEL 7 stable repository.