Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.3-1.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.3-1.src.rpm Description: Asterisk is a complete PBX in software. It runs on Linux and provides all of the features you would expect from a PBX and more. Asterisk does voice over IP in three protocols, and can interoperate with almost all standards-based telephony equipment using relatively inexpensive hardware.
> %{_sbindir}/asterisk > %{_sbindir}/astgenkey > %{_sbindir}/astman > %{_sbindir}/autosupport > %{_sbindir}/rasterisk > %{_sbindir}/safe_asterisk > %{_sbindir}/smsq > %{_sbindir}/stereorize > %{_sbindir}/streamplayer You should probably do %{_sbindir}/* instead ? > > %{_mandir}/man8/asterisk.8* > %{_mandir}/man8/astgenkey.8* > %{_mandir}/man8/autosupport.8* > %{_mandir}/man8/safe_asterisk.8* How about %{_mandir}/man8/* > > %defattr(-,asterisk,asterisk,-) > > %dir %{_sysconfdir}/asterisk > %config(noreplace) %{_sysconfdir}/asterisk/adsi.conf > %config(noreplace) %{_sysconfdir}/asterisk/adtranvofr.conf ... <snip> ... > %config(noreplace) %{_sysconfdir}/asterisk/zapata.conf Enumerating all the conf files is rather and prone to omission when something new gets added in a future version. You kind-of have to do it here because you want postgres and odbc conf files in separate subpackages. Here's a question for the more experienced packagers on the list: Is there a way to specify "all files in a directory *except* foo, bar, and blah" ?
(In reply to comment #1) > %{_sbindir}/* [...] > %{_mandir}/man8/* [...] > Enumerating all the conf files is rather and prone to omission when > something new gets added in a future version. Actually, many packagers prefer to explicitly enumerate things that should be in a package so that an omitted file won't go unnoticed (rpmbuild will fail on installed but unpackaged files), and that new files won't accidentally sneak in. Use of wildcards means that neither of these will be noticed. They're useful sometimes though. > Is there a way to specify "all files in a directory *except* foo, bar, > and blah" ? /a/* %exclude /a/foo %exclude /a/bar %exclude /a/blah Caveat on using %exclude: https://bugzilla.redhat.com/89661
Update Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.3-1.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.3-1.src.rpm * Wed Jan 25 2006 Jeffrey C. Ollie <jeff> - 1.2.3-4 - Took some tricks from Asterisk packages by Roy-Magne Mo. - Enable gtk console module. - BR gtk+-devel. - Add logrotate script. - BR sqlite2-devel and new sqlite subpackage. - BR doxygen and graphviz for building duxygen documentation. (But don't build it yet.) - Update IP TOS patch. * Wed Jan 25 2006 Jeffrey C. Ollie <jeff> - 1.2.3-3 - Completely eliminate the "asterisk" user from the spec file. - Move more config files to subpackages. - Consolidate two patches that patch the init script. - BR curl-devel - BR alsa-lib-devel - alsa, curl, oss subpackages * Wed Jan 25 2006 Jeffrey C. Ollie <jeff> - 1.2.3-2 - Do not run as user "asterisk" as that prevents setting of IP TOS (which is bad for quality of service). - Add patch for setting TOS separately for SIP and RTP packets.
(In reply to comment #2) > (In reply to comment #1) > > %{_sbindir}/* > [...] > > %{_mandir}/man8/* > [...] > > Enumerating all the conf files is rather and prone to omission when > > something new gets added in a future version. > > Actually, many packagers prefer to explicitly enumerate things that should be in > a package so that an omitted file won't go unnoticed (rpmbuild will fail on > installed but unpackaged files), and that new files won't accidentally sneak in. > Use of wildcards means that neither of these will be noticed. This is exactly my sentiment. I want to know what I'm putting into the package. If a new version comes out that adds/removes a file, I'll know about it when I try and build the new version and can deal with it.
just some general info/rant about asterisk since i deployed it various times already on production servers. actually to have bri cards working there are 3 ways. misdn bristuff and visdn. misdn: broken piece and the upstream dev wrote me half a year ago that he wants to get it into the standard kernel (nothing i can see happened though) bristuff: ugly hack that requires you to patch various compenents including zaptel and asterisk. visdn: seems to be the new shiny solution to all that mess. hope that helps while its not directly relevant for the package itsself in my eyes that infos are still relevant for getting a production ready asterisk. bri cards are rather widespread because they are relatively cheap (junghanns/beronet quad and octo cards e.g.)
just curious... why do you "noreplace" all configs? dont we want to have the unmodified default configs replaced?
(In reply to comment #5) > > actually to have bri cards working there are 3 ways. > > misdn bristuff and visdn. > > [...] > > hope that helps while its not directly relevant for the package itsself in my > eyes that infos are still relevant for getting a production ready asterisk. > > bri cards are rather widespread because they are relatively cheap > (junghanns/beronet quad and octo cards e.g.) My Asterisk package does not at this time include support for plain 'ol Zaptel cards. I know that this leaves Europeans in a bit of a lurch because of all of the BRI hardware over there. I'll look into the various BRI options once the base Asterisk package is approved and see if I can't get something into FE. (In reply to comment #6) > just curious... why do you "noreplace" all configs? dont we want to have the > unmodified default configs replaced? Users may or may not be depending on the configuration that is in the "default" configuration files. If the default configuration files change it would be better for the administrator to manually take a look at all of the .rpmnew files and decide if any changes are going to break his/her setup.
(In reply to comment #7) > (In reply to comment #5) > > > > actually to have bri cards working there are 3 ways. > > > > misdn bristuff and visdn. > > > > [...] > > > > hope that helps while its not directly relevant for the package itsself in my > > eyes that infos are still relevant for getting a production ready asterisk. > > > > bri cards are rather widespread because they are relatively cheap > > (junghanns/beronet quad and octo cards e.g.) > My Asterisk package does not at this time include support for plain 'ol Zaptel > cards. I know that this leaves Europeans in a bit of a lurch because of all of > the BRI hardware over there. I'll look into the various BRI options once the > base Asterisk package is approved and see if I can't get something into FE. Yup thats pretty fine to me i just wanted to point out the problem in general. visdn seems to be the cleanest solution though. only backdraw yet is missing echo suppression since its young. > (In reply to comment #6) > > just curious... why do you "noreplace" all configs? dont we want to have the > > unmodified default configs replaced? > Users may or may not be depending on the configuration that is in the "default" > configuration files. If the default configuration files change it would be > better for the administrator to manually take a look at all of the .rpmnew files > and decide if any changes are going to break his/her setup. well but how about the other case? lets assume we go ahead various versions of asterisk... and how high do you eval the chance the the old config will be broken in newer releases? in my eyes if they werent changed by the user they should really be replaced by the new versions default configs. i am not sure if theres a policy regarding that or not. just an opinion.
(In reply to comment #8) > lets assume we go ahead various versions of asterisk... and how high do you > eval the chance the the old config will be broken in newer releases? in my eyes > if they werent changed by the user they should really be replaced by the new > versions default configs. i am not sure if theres a policy regarding that or > not. %config(noreplace) does not mean that unedited config files will not be replaced - they will. The difference in behaviour between %config and %config(noreplace) comes in when the user has edited the config file. With %config, the user's edited file will be renamed to file.rpmsave and the new package's config file will take its place. With %config(noreplace), the user's edited file will be left alone and the new package's file will be installed as file.rpmnew. %config(noreplace) should generally be used for config files unless there's a good reason not to use (noreplace).
> lets assume we go ahead various versions of asterisk... and how high do you > eval the chance the the old config will be broken in newer releases? in my eyes > if they werent changed by the user they should really be replaced by the new > versions default configs. i am not sure if theres a policy regarding that or > not. %config(noreplace) does not mean that unedited config files will not be replaced - they will. The difference in behaviour between %config and %config(noreplace) comes in when the user has edited the config file. With %config, the user's edited file will be renamed to file.rpmsave and the new package's config file will take its place. With %config(noreplace), the user's edited file will be left alone and the new package's file will be installed as file.rpmnew. %config(noreplace) should generally be used for config files unless there's a good reason not to use (noreplace). well(In reply to comment #9) > (In reply to comment #8) > > lets assume we go ahead various versions of asterisk... and how high do you > > eval the chance the the old config will be broken in newer releases? in my eyes > > if they werent changed by the user they should really be replaced by the new > > versions default configs. i am not sure if theres a policy regarding that or > > not. > %config(noreplace) does not mean that unedited config files will not be replaced > - they will. The difference in behaviour between %config and %config (noreplace) > comes in when the user has edited the config file. With %config, the user's > edited file will be renamed to file.rpmsave and the new package's config file > will take its place. With %config(noreplace), the user's edited file will be > left alone and the new package's file will be installed as file.rpmnew. > %config(noreplace) should generally be used for config files unless there's a > good reason not to use (noreplace). if thats the behaviour i am pretty fine with it. p.s. back then when i last looked at it i couldnt find proper documentation about %config really. thanks for clearing that.
(In reply to comment #7) > > My Asterisk package does not at this time include support for plain 'ol Zaptel > cards. Uhh.. this should have been "My Asterisk package _only_ includes support for plain 'ol Zaptel cards."
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.4-1.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.4-1.src.rpm * Tue Jan 31 2006 Jeffrey C. Ollie <jeff> - 1.2.4-1 - Update to 1.2.4.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.4-2.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.4-2.src.rpm * Mon Feb 6 2006 Jeffrey C. Ollie <jeff> - 1.2.4-2 - BR sqlite2-devel
A simple solution for the %config(noreplace) issue that I have used over the years is simply putting the samples in /etc/asterisk-samples-%{version}. Having run Asterisk in a production environment at a Telco I prefer rpm _not_ to touch my Asterisk config files ever.
chan_skinny listen by default on port 2000/tcp, and most people would never use the skinny protocol with asterisk. Asterisk should either not load this module, not listen on the port or put chan_skinny in its own package.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.5-1.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.5-1.src.rpm * Mon Mar 6 2006 Jeffrey C. Ollie <jeff> - 1.2.5-1 - Update to 1.2.5. - Removed upstreamed MOH patch. - Add full urls to the app_(r|t)xfax.c sources. - Update spandsp patch.
A few comments : - Asterisk shouldn't run as root by default IMHO. If it's a QoS related decision, it should be up to the user/admin to switch to using root. - I've had to replace /var/run with a sub-dir to have asterisk run as non-root - I've had to add some further ugly replacing to fix lib vs. lib64 issues. - The logrotate file should be %config(noreplace) in case people edit it. - I'm not totally convinced about the need for some of the sub-packages. For instance oss, alsa, curl and sounds-default. - Why is the manually installed asterisk.h file needed? My current spec and other files : http://svn.rpmforge.net/svn/trunk/rpms/asterisk/
any chance for a update to 1.2.6?
(In reply to comment #18) > any chance for a update to 1.2.6? Here are the 1.2.6 packages. I have had these for a while but didn't announce them because there was talk of a new release that was supposed to happen shortly after 1.2.6 but the release was held back while another bug is hunted down. Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.6-1.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.6-1.src.rpm
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.6-3.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.6-3.src.rpm * Mon Apr 10 2006 Jeffrey C. Ollie <jeff> - 1.2.6-3 - Fix detection of libpri on 64 bit arches (taken from Matthias Saou's rpmforge package) - Change sqlite subpackage name to sqlite2 (there are sqlite3 modules in development). * Thu Apr 6 2006 Jeffrey C. Ollie <jeff> - 1.2.6-2 - Don't build GTK 1.X console since GTK 1.X is being moved out of core...
It would also be nice to include the extra sounds.
Or rather in a separate rpm (I see that Matthias packages them in asterisk-sounds).
Keep in mind that some sound files are present in both the asterisk and asterisk-sounds sources, so you also get some "nice" conflicts, which even happen to change every once in a while (files added here, removed there...).
(In reply to comment #23) > Keep in mind that some sound files are present in both the asterisk and > asterisk-sounds sources, so you also get some "nice" conflicts, which even > happen to change every once in a while (files added here, removed there...). The conflicting sounds were removed from the SVN repo a while back, but there hasn't been a new release of the tarball. There are also some French prompts available in the SVN repository which would be good to have packaged at some time.
(In reply to comment #22) > Or rather in a separate rpm (I see that Matthias packages them in asterisk-sounds). A separate source RPM would be good because then the RPM that contains the sounds can be a noarch package.
(In reply to comment #24) > (In reply to comment #23) > > Keep in mind that some sound files are present in both the asterisk and > > asterisk-sounds sources, so you also get some "nice" conflicts, which even > > happen to change every once in a while (files added here, removed there...). > > The conflicting sounds were removed from the SVN repo a while back, but there > hasn't been a new release of the tarball. There are also some French prompts > available in the SVN repository which would be good to have packaged at some time. I've built rpms using Matthias spec files for asterisk (1.2.6) and asterisk-sounds (1.2.1) and there aren't any conflicting files.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.7-1.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.7-1.src.rpm
> I've built rpms using Matthias spec files for asterisk (1.2.6) and > asterisk-sounds (1.2.1) and there aren't any conflicting files. That's because all the conflicting sounds are %exclude'd in the asterisk-sounds package :-) But if this has now been fixed upstream, it's a good thing. And yes, the sounds make much more sense in a separate noarch rpm.
(In reply to comment #28) > That's because all the conflicting sounds are %exclude'd in the asterisk-sounds > package :-) But if this has now been fixed upstream, it's a good thing. And yes, > the sounds make much more sense in a separate noarch rpm. I confess I was too lazy to read the spec file (specially since it worked first hand)... ;-)
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.7.1-1.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.7.1-1.src.rpm
Please build with mISDN. Also include app_conference if you don't already, because we really don't want to require zaptel. The mISDN and Zaptel Asterisk modules should probably go into separate sub-packages, which can require the corresponding kernel modules. Including chan_bluetooth would also be good.
Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.7.1-3.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.7.1-3.src.rpm %changelog * Thu Apr 20 2006 Jeffrey C. Ollie <jeff> - 1.2.7.1-3 - Add chan_bluetooth * Wed Apr 19 2006 Jeffrey C. Ollie <jeff> - 1.2.7.1-2 - Split off more stuff into subpackages.
(In reply to comment #31) > Please build with mISDN. That looks like it will take packaging up some other libs. I'll look into what it takes to get those packaged up. > Also include app_conference if you don't already, > because we really don't want to require zaptel. Just adding app_conference and moving some modules to a subpackage won't completely eliminate dependencies on Zaptel. There are some parts of the Asterisk core that use Zaptel timing channels (it's *supposed* to work without Zaptel being present but I haven't verified that). > The mISDN and Zaptel Asterisk modules should probably go into separate > sub-packages, which can require the corresponding kernel modules. The latest package moves some modules that depend on Zaptel to a subpackage. mISDN support will definitely be a subpackage if/when I get to it. > Including chan_bluetooth would also be good. See latest packages. I used the version I found on cvs.infradead.org to generate the patch. Let me know if there's a different version that I should have used.
(In reply to comment #31) > Please build with mISDN. After taking a look at mISDN I think that I'm going to have to let someone else package the mISDN libs/drivers. Once the mISDN libs have been packaged I'll enable the mISDN channel in Asterisk.
as far as i know misdn requires a kernel patch aswell. not sure if its buildable without patching the kernel. personally i have only messed with visdn (and packaged it in an ugly way for myself). visdn has been certified in italy and doesent require a kernel patch. afaik it only works with euroisdn yet though. not sure if misdn is certifiable at all.
mISDN doesn't need a kernel patch -- you only need to build its modules. I did look at building mISDN as a separate package, but in the end I believe I decided it was probably better to build it as part of the Asterisk package and just ship it with the chan_misdn module. I don't think it's worth shipping separate mISDN and mISDN-devel packages just for Asterisk to use. I don't recall where the original specfile came from, but the one I find lying around unfinished in my working tree is now at http://david.woodhou.se/asterisk.spec
OK, looking further into the mISDN issue: Do the Fedora kernels have the mISDN kernel modules? If not, it would mean that people would need to manually compile/install the mISDN kernel modules to use the mISDN channel from Asterisk, something that's bound to be error-prone. Looking at the Makefile in channels/misdn in the Asterisk source, there's a "test_preempt" target that checks the kernel config for "CONFIG_DEBUG_SPINLOCK=y", "CONFIG_DEBUG_SPINLOCK_SLEEP=y" and "CONFIG_SMP=y" and also checks to see if GCC v4 is installed. It claims that the mISDN channel won't work if any of these conditions are true. It would appear that for current Fedora development all four of these conditions are true, and for Fedora Core 4 kernels at least 3 of the conditions are true.
We might want to ship the kernel modules in a separate package, yes. I believe the mqueue branch of mISDN, which is what chan_misdn should now be using, solves all the above-mentioned problems with locking and compilers. That's an issue for the kernel-modules package though; the userspace bit is fine.
(In reply to comment #38) > We might want to ship the kernel modules in a separate package, yes. I believe > the mqueue branch of mISDN, which is what chan_misdn should now be using, solves > all the above-mentioned problems with locking and compilers. That's an issue for > the kernel-modules package though; the userspace bit is fine. chan_misdn in 1.2 seems to require a specific version of the mISDN libraries that is almost a year old now. chan_misdn in SVN trunk seems to want a newer mISDN library version. It makes sense to me to worry about supporting mISDN after Asterisk 1.4 is release.
(In reply to comment #31) > Including chan_bluetooth would also be good. chan_bluetooth is of questionable quality AFAIK, so I don't know if this is wise to include. Couldn't this be in a separate package?
(In reply to comment #40) > (In reply to comment #31) > > > Including chan_bluetooth would also be good. > > chan_bluetooth is of questionable quality AFAIK, so I don't know if this is wise > to include. Couldn't this be in a separate package? I don't know about the quality (I don't have the necessary equipment to test with), but I packaged chan_bluetooth as a separate subpackage.
Should the zaptel subpackage really obsolete the sqlite subpackage?
(In reply to comment #42) > Should the zaptel subpackage really obsolete the sqlite subpackage? Oops, no that's a cut-n-pasto on my part. Updated Spec/SRPM: Spec Name or Url: http://www.ocjtech.us/asterisk-1.2.7.1-3.spec SRPM Name or Url: http://www.ocjtech.us/asterisk-1.2.7.1-3.src.rpm %changelog * Tue May 2 2006 Jeffrey C. Ollie <jeff> - 1.2.7.1-6 - Zaptel subpackage shouldn't obsolete the sqlite subpackage. - Remove mISDN until build issues can be figured out. * Mon Apr 24 2006 Jeffrey C. Ollie <jeff> - 1.2.7.1-5 - Build mISDN channel drivers, modelled after spec file from David Woodhouse * Thu Apr 20 2006 Jeffrey C. Ollie <jeff> - 1.2.7.1-4 - Update chan_bluetooth patch with some additional information as to it's source and comment out more in the configuration file.
(In reply to comment #43) > %changelog > * Tue May 2 2006 Jeffrey C. Ollie <jeff> - 1.2.7.1-6 > - Zaptel subpackage shouldn't obsolete the sqlite subpackage. > - Remove mISDN until build issues can be figured out. Installed (but unpackaged) file(s) found: /etc/asterisk/misdn.conf Seems to be some leftovers :)
Security: http://www.asterisk.org/node/95
(In reply to comment #45) > Security: http://www.asterisk.org/node/95 Yup... I'm working on new SRPMs for Asterisk and related packages... just waiting for some local mock builds to finish.
I've uploaded new SRPMs for Asterisk and related packages. Right now only the new SRPMs are there, I'll extract the spec files later... http://repo.ocjtech.us/asterisk-1.2/fedora/5/SRPMS/
any chance for a update to 1.2.10 for asterisk?
(In reply to comment #48) > any chance for a update to 1.2.10 for asterisk? http://repo.ocjtech.us/asterisk-1.2/fedora/5/SRPMS/asterisk-1.2.10-1.fc5.spec http://repo.ocjtech.us/asterisk-1.2/fedora/5/SRPMS/asterisk-1.2.10-1.fc5.src.rpm
I've just attempted to rebuild the SRPM, and I get this: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -DZAPTEL_OPTIMIZATIONS -fomit-frame-pointer -Wno-missing-prototypes -Wno-missing-declarations -DZAPATA_PRI -DIAX_TRUNKING -DCRYPTO -fPIC -c -o chan_phone.o chan_phone.c chan_phone.c:41:29: error: linux/compiler.h: No such file or directory chan_phone.c: In function 'phone_write': chan_phone.c:750: warning: value computed is not used make[1]: *** [chan_phone.o] Error 1 Perhaps another buildreq missing?
http://lists.digium.com/pipermail/asterisk-dev/2006-July/021652.html(In reply to comment #50) > > > Perhaps another buildreq missing? Something changed kernel-wise: http://lists.digium.com/pipermail/asterisk-dev/2006-July/021652.html
A couple of vulnerabilities reported against 1.2.10: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-4345 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-4346
Assigning to myself. It'll be a week or two before I'm home and able to look at it though -- so if anyone else wants to steal it from me and approve it in that time, feel free.
Should we be using sqlite2 instead of 'sqlite' which is sqlite v3?
We should build without -DZAPTEL_OPTIMIZATIONS. The timing stuff can be done with POSIX timers instead, and then I think the use of the zaptel devices is restricted to chan_zap and app_meetme. We should include app_conference. Since we're unlikely to ship zaptel kernel modules until/unless they're merged upstream, we need to make 100% sure they're _optional_ for our build of Asterisk.
Start of POSIX timer stuff here: http://lists.digium.com/pipermail/asterisk-dev/2005-May/012906.html pselect() does work now.
So is it possible to build asterisk so it works fine without zaptel modules, but will work with them if they were installed from something like a 3rd party repository? ie, dynamic detection of them? also, if you are reviewing this perhaps change the blocker from FE_NEW to FE_REVIEW? :)
Yes, that's the plan.
It can't pass a review while it still requires zaptel and libpri packages which aren't in Fedora -- let's disable those for the 'asterisk' package, and build them as a separate package for now. We can't put spandsp into Extras either -- that has to be in Livna. So app_[rt]xfax need to be omitted from the package too.
Looking at the spandsp review bug, it seems I was wrong -- we can put spandsp in. I've also been looking at OpenPBX, which is apparently due for release soon. I'm not particularly impressed by their political reasons for forking Asterisk, but they have a codebase which: - Uses POSIX timers instead of ztdummy - Contains app_conference, again not requiring zaptel - Contains chan_bluetooth I wonder if OpenPBX would be a better choice for packaging in Extras, if Digium refuse to put their kernel modules upstream and refuse to remove the most gratuitous dependencies on them.
OpenPBX has been due for release soon for a long time now... While OpenPBX has progressed on the fronts that you mention, other parts of the code that were inherited from Asterisk have seen little or no maintenance, while Asterisk has had many security and bug fixes applied. OpenPBX has lofty goals and I applaud what they have done so far... however I fear that there are just too few people working on the OpenPBX code to keep up with security and bug fixes.
If we ship OpenPBX in Fedora then I'm sure its developer base will increase. And where they're using code inherited from Asterisk, can't they just port fixes from Asterisk too? But I really would prefer to ship Asterisk itself. The only reason I'm even considering OpenPBX is because of the _technical_ improvements -- mainly eliminating the _requirement_ for zaptel, and shipping app_conference. Let's go ahead with an Asterisk package without zaptel for now, and then work on getting the rest up to scratch. http://david.woodhou.se/asterisk/asterisk.spec http://david.woodhou.se/asterisk/asterisk-1.2.12.1-1.src.rpm Oh, I took spandsp out of that too -- I'll put it back.
Spec: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-0.fc6.beta2.spec SRPM: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-0.fc6.beta2.src.rpm %changelog * Sun Oct 15 2006 Jeffrey C. Ollie <jeff> - 1.4.0-0.beta2 - Update to 1.4.0-beta2
Spec: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-1.fc6.beta3.spec SRPM: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-1.fc6.beta3.src.rpm Update to 1.4.0-beta3
Spec: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-3.fc6.beta3.spec SRPM: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-3.fc6.beta3.src.rpm %changelog * Wed Oct 18 2006 Jeffrey C. Ollie <jcollie.dmacc.edu.> - 1.4.0-3.beta3 - *Really* update to beta3 - chan_jingle has been taken out of 1.4 - Move misplaced binaries to where they should be * Wed Oct 18 2006 Jeffrey C. Ollie <jeff> - 1.4.0-2.beta3 - Remove requirement on asterisk-sounds-core until licensing can be figured out.
There's no need to BuildRequires: glibc-kernheaders. If you were doing it with a specific version, that might make sense. But you'll not get far building _anything_ without glibc-kernheaders, so it's part of the base set of packages. Why don't you build res_jabber on ppc? It builds for OpenPBX. Seems to require lm_sensors-devel which doesn't exist. Fails to build: menuselect/menuselect --check-deps menuselect.makeopts *********************************************************** The existing menuselect.makeopts file did not specify that 'chan_gtalk' should not be included. However, either some dependencies for this module were not found or a conflict exists. Either run 'make menuselect' or remove the existing menuselect.makeopts file to resolve this issue. *********************************************************** make[1]: *** [menuselect.makeopts] Error 255
(In reply to comment #66) > There's no need to BuildRequires: glibc-kernheaders. If you were doing it with a > specific version, that might make sense. But you'll not get far building > _anything_ without glibc-kernheaders, so it's part of the base set of packages. Ah, I didn't realize that it's part of the base install. It's needed to build chan_phone. The build of chan_phone works on FC-5 but not devel because the configure script is looking for <linux/compiler.h> which is not in the kernel-headers package in devel. > Why don't you build res_jabber on ppc? It builds for OpenPBX. res_jabber on OpenPBX uses loudmouth to process XMPP messages. Asterisk uses iksemel to perform similar functions. The iksemel package has self tests that fail on non-i386 architectures so it isn't packaged currently for non-i386 architectures. > Seems to require lm_sensors-devel which doesn't exist. Yeah, that seems to be another package that is excluded on PPC. Unfortunately, lm_sensors is needed to build the res_snmp package on i386 and x86_64, but isn't pulled in automatically by net-snmp-devel. > Fails to build: > menuselect/menuselect --check-deps menuselect.makeopts > > *********************************************************** > The existing menuselect.makeopts file did not specify > that 'chan_gtalk' should not be included. However, either some > dependencies for this module were not found or a > conflict exists. > > Either run 'make menuselect' or remove the existing > menuselect.makeopts file to resolve this issue. > *********************************************************** > > make[1]: *** [menuselect.makeopts] Error 255 Another casualty of iksemel probably.
(In reply to comment #67) > The iksemel > package has self tests that fail on non-i386 architectures so it isn't > packaged currently for non-i386 architectures. For reference, there's a bug open on this issue: bug #200579.
A couple of other issues: 1) There are no sounds packaged. The sound files, while not essential, are extremely important for full functionality. Unfortunately, the licensing of the sound file isn't clear. They are package separately from the source code but do not have any licensing information attached. Here are links to a thread that I started on the asterisk-dev mailing list: http://lists.digium.com/pipermail/asterisk-dev/2006-October/024096.html http://lists.digium.com/pipermail/asterisk-dev/2006-October/024113.html Once the licensing is sorted out, I have packages ready for review. There are some Music on Hold sound archives as well, but the license on those would seem to prohibit inclusion in Fedora. 2) The Asterisk makefiles are capable of downloading the sound packages from Digium's FTP server. I haven't gotten that completely blocked so if you try to rebuild the package it will download some of the sound archives.
Including <linux/compiler.h> is just a bug, and should be fixed upstream. The iksemel package exists on PowerPC -- you can enable jabber there, and then you're right; gtalk seems to work too. lm_sensors doesn't seem to be necessary either. app_rpt needs to either die completely, use a proper kernel driver or be limited to architectures where you're allowed to poke randomly at I/O ports from userspace.
Spec: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-5.fc6.beta3.spec SRPM: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-5.fc6.beta3.src.rpm * Fri Oct 20 2006 Jeffrey C. Ollie <jeff> - 1.4.0-5.beta3 - Don't package IAXy firmware because of license - Don't build app_rpt - Don't BR lm_sensors on PPC - Better way to prevent download/installation of sound archives - Redo tarball to eliminate non-free items * Thu Oct 19 2006 Jeffrey C. Ollie <jeff> - 1.4.0-4.beta3 - Remove explicit dependency on glibc-kernheaders. - Add patch to remove linux/compiler.h dependency. - Build jabber modules on PPC
Spec: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-6.beta4.fc7.spec SRPM: http://repo.ocjtech.us/asterisk-1.4/fedora/development/SRPMS/asterisk-1.4.0-6.beta4.fc7.src.rpm %changelog * Fri Dec 15 2006 Jeffrey C. Ollie <jeff> - 1.4.0-6.beta4 - Update to 1.4.0-beta4 - Various cleanups.
Have you had a chance to look at upgrading to 1.4.0 final? Are there any major blockers to getting this into Extras now? This review is getting rather long, so I'm not quite sure... :-)
One other thought... It might be worth making some of the features that are being excluded due to license and patent issues optional in the spec, obviously defaulting to off. That might make it easier to re-enable those features as some of the license issues are resolved, plus it would be useful for people who didn't mind rebuilding a local copy.
I'm upgrading my phone system today, so pardon the noise. :-) Issue #1: In the script you use to modify the source from Digium, you have this: # tar xf asterisk-1.4.0-beta4.tar.gz That should have been this: # tar zxf asterisk-1.4.0-beta4.tar.gz Other than that, following the directions does indeed give me identical sources (according to "diff -urN") to the source included in the src.rpm. Issue #2: I'd suggest changing %post to something like this: /sbin/chkconfig --add asterisk || : /sbin/service asterisk condrestart || : If there is a good way to do a graceful restart here, that would be even better. I'd also prefer it if %pre and %preun looked like this: %pre /usr/sbin/fedora-groupadd 31 -r asterisk || : /usr/sbin/fedora-useradd 31 -r -s /sbin/nologin -d /var/lib/asterisk -M \ -c 'Asterisk User' -g asterisk asterisk || : %preun if [ $1 = 0 ]; then /sbin/service asterisk stop || : /sbin/chkconfig --del asterisk || : fi That way we see failures, but they don't make rpm fail. When I installed the packages on my phone system (which had old asterisk/zaptel/libpri packages of mine, which might be the problem), I got the following error: Installing: zaptel ####################### [ 9/13] id: asterisk: No such user usermod: user asterisk does not exist error: %pre(asterisk-zaptel-1.4.0-6.beta4.fc6.i386) scriptlet failed, exit status 6 error: install: %pre scriptlet failed (2), skipping asterisk-zaptel-1.4.0-6.beta4.fc6 Since the asterisk %pre was redirected to /dev/null, I have no idea if there was a failure there. Again, the real problem might have been caused by old packages, but, since I don't have diagnostic output, I can't be sure. I would definitely test an install on a clean system though to be safe. So far those are the only problems that I've found. The package builds fine in mock (i386 and x86_64), and the handful of rpmlint warnings can be safely ignored.
1.4 final shouldn't be that different from the last beta. Hopefully I'll have new SRPMS up in a day or so.
I just noticed one more thing... Should app_mp3 even be built? It's pretty worthless since "real" mpg123 isn't even available in livna.
Next problem... Without the core sounds, an attempt to use blind transfer disconnects the call. [Jan 3 12:02:06] WARNING[7091]: file.c:553 ast_openstream_full: File pbx-transfer does not exist in any format [Jan 3 12:02:06] WARNING[7091]: file.c:805 ast_streamfile: Unable to open pbx-transfer (format 0x8 (alaw)): No such file or directory == Spawn extension (remote, s, 2) exited non-zero on 'Zap/2-1' -- Hungup 'Zap/2-1' If we can't freely redistribute the core sounds, should the package maybe include an easy way to download them? (Or is the license on the sounds free enough that they can be distributed in a separate package?)
Hmmm yeah, I keep forgetting about the sounds... I don't think that the sounds free enough to be included in Fedora, because ISTR that they place restrictions on using the sounds with anything but Asterisk. I wasn't able to find the exact wording of the licensing though. They also don't include the "source" (the high-quality masters) but that may or may not be a problem.
OpenPBX sounds are OK though -- can we use those?
(In reply to comment #80) > OpenPBX sounds are OK though -- can we use those? The majority of the OpenPBX and Asterisk sounds probably still use the same script (except for "OpenPBX" being substituted for "Asterisk" of course). How annoying those differences between the scripts would take some experimentation.
AFAIK, we have other packages which come with media that may only be used with that package, and that has never been a problem. remember sounds == content != code. For content the only demands are that: 1 its usefull for some program, iow no random photo collections, 2 its freely redistributable (together with the program using it). So I see no problem to just use the asterisk sounds, other wise ask Spot.
Spec: http://repo.ocjtech.us/misc/fedora/development/SRPMS/asterisk-1.4.1-1.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/development/SRPMS/asterisk-1.4.1-1.fc7.src.rpm * Mon Mar 5 2007 Jeffrey C. Ollie <jeff> - 1.4.1-1 - Update to 1.4.1 - Don't build/package codec_zap (zaptel 1.4.0 doesn't support it) I'll take a look at packaging the sounds soon. Also given the recent discussion about packaging wireless firmware I think that I can package the IAXy firmware. I've posted a query to the fedora-packaging mailing list. If I get positive feedback from that query I'll update the package with the IAXy firmware.
Spec: http://repo.ocjtech.us/misc/fedora/development/SRPMS/asterisk-1.4.1-2.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/development/SRPMS/asterisk-1.4.1-2.fc7.src.rpm * Tue Mar 6 2007 Jeffrey C. Ollie <jeff> - 1.4.1-2 - Package the IAXy firmware - Minor clean-ups in files
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1561 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1594 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1595
Yeah, I know about 1.4.2, unfortunately v1.4.2 requires v1.4.1 of Zaptel (which wasn't released until several days AFTER Asterisk 1.4.2 was). There were some new features added that requires new features in the newer Zaptel (so much for the no new features policy of 1.4.x). Unfortunately I've had some trouble getting Zaptel 1.4.1 built...
Spec: http://repo.ocjtech.us/misc/fedora/6/SRPMS/asterisk-1.4.3-1.fc6.spec SRPM: http://repo.ocjtech.us/misc/fedora/6/SRPMS/asterisk-1.4.3-1.fc6.src.rpm Update to 1.4.3 to fix some more security problems.
Spec: http://repo.ocjtech.us/misc/fedora/6/SRPMS/asterisk-1.4.4-1.fc6.spec SRPM: http://repo.ocjtech.us/misc/fedora/6/SRPMS/asterisk-1.4.4-1.fc6.src.rpm Bugfix release.
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-2488 "The IAX2 channel driver (chan_iax2) in Asterisk before 20070504 does not properly null terminate data, which allows remote attackers to trigger loss of transmitted data, and possibly obtain sensitive information (memory contents) or cause a denial of service (application crash), by sending a frame that lacks a 0 byte."
Spec: http://repo.ocjtech.us/misc/fedora/6/SRPMS/asterisk-1.4.4-2.fc6.spec SRPM: http://repo.ocjtech.us/misc/fedora/6/SRPMS/asterisk-1.4.4-2.fc6.src.rpm * Wed May 9 2007 Jeffrey C. Ollie <jeff> - 1.4.4-2 - Add a patch to fix CVE-2007-2488/ASA-2007-013
What about this point from comment #17? > - Asterisk shouldn't run as root by default IMHO. If it's a QoS related > decision, it should be up to the user/admin to switch to using root. I've checked the 1.4.4 packages, and asterisk still defaults to running as root. While looking at this, I also noticed that the init script includes a commented out configuration section even though it supports setting all the options by creating an /etc/sysconfig/asterisk file. Since no configuration changes should be made inside the init script itself (this is now a policy), I'd suggest : - Installing a default /etc/sysconfig/asterisk file - Moving the "configuration" section from the init script to that file Also, unless it's absolutely impossible to run asterisk as non-root (which I doubt, since all my installs run as the asterisk user), I'd suggest having the /etc/sysconfig/asterisk file default to switching to the asterisk user and group, with a comment saying that by commenting out the entries, asterisk would run as root, that it might be useful in some setups, but that it also involves a higher risk.
The Mandriva asterisk packages run as non-root. Feel free to check & see how they did it.
David: Are you reviewing this package? I am going to go ahead and set the fedora-review flag to ? thinking that you are doing so. If you aren't could you set it back to " " and reassign it to nobody so someone else could move it forward?
where are asterisk-addons to use mysql cdr support ?
(In reply to comment #94) > where are asterisk-addons to use mysql cdr support ? I have not packaged asterisk-addons.
(In reply to comment #95) > (In reply to comment #94) > > where are asterisk-addons to use mysql cdr support ? > I have not packaged asterisk-addons. asterisk-addons is necessary for mysql cdr billing.
(In reply to comment #96) > (In reply to comment #95) > > (In reply to comment #94) > > > where are asterisk-addons to use mysql cdr support ? > > I have not packaged asterisk-addons. > > asterisk-addons is necessary for mysql cdr billing. True, but after ~18 months I have not gotten Asterisk approved for inclusion, so I'm going to work on that. I have no personal need for anything in asterisk-addons, so once Asterisk is approved someone else is welcome to work on packaging asterisk-addons.
Spec: http://repo.ocjtech.us/misc/fedora/development/SRPMS/asterisk-1.4.5-1.fc8.spec SRPM: http://repo.ocjtech.us/misc/fedora/development/SRPMS/asterisk-1.4.5-1.fc8.src.rpm Update to 1.4.5.
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.5-9.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.5-9.fc7.src.rpm * Mon Jun 18 2007 Jeffrey C. Ollie <jeff> - 1.4.5-9 - Move sounds * Mon Jun 18 2007 Jeffrey C. Ollie <jeff> - 1.4.5-8 - Update some more ownership/permissions * Mon Jun 18 2007 Jeffrey C. Ollie <jeff> - 1.4.5-7 - Fix some permissions. * Mon Jun 18 2007 Jeffrey C. Ollie <jeff> - 1.4.5-6 - Update init script patch - Move pid file to subdir of /var/run * Mon Jun 18 2007 Jeffrey C. Ollie <jeff> - 1.4.5-5 - Update init script patch to run as non-root * Sun Jun 17 2007 Jeffrey C. Ollie <jeff> - 1.4.5-4 - Build modules that depend on FreeTDS. - Don't build voicemail with ODBC storage. * Sun Jun 17 2007 Jeffrey C. Ollie <jeff> - 1.4.5-3 - Have the build output the commands executing, rather than covering them up.
I've sent another query to the asterisk-dev mailing list about licenses for the sounds: http://lists.digium.com/pipermail/asterisk-dev/2007-June/028166.html
Response from Digium about license for sounds: http://lists.digium.com/pipermail/asterisk-dev/2007-June/028176.html
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.5-10.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.5-10.fc7.src.rpm * Thu Jun 21 2007 Jeffrey C. Ollie <jeff> - 1.4.5-10 - Build the IMAP and ODBC storage options of voicemail and split voicemail out into subpackages. - Apply patch so that the system UW IMAP libray can be linked against. - Patch modules.conf.sample so that alternal voicemail modules don't get loaded simultaneously. - Link against system GSM library rather than internal copy. - Patch the Makefile so that it doesn't add redundant/wrong compiler options. - Force building with the standard RPM optimization flags. - Install the Asterisk MIB in a location that net-snmp can find it. - Only package docs in the main package that are relevant and that haven't been packaged by a subpackage. - Other minor cleanups.
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.6-1.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.6-1.fc7.src.rpm Update to 1.4.6
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.7-1.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.7-1.fc7.src.rpm Update to 1.4.7
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.7.1-1.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.7.1-1.fc7.src.rpm Update to 1.4.7.1
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.8-1.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.8-1.fc7.src.rpm Update to 1.4.8 - several important security updates.
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.9-1.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.9-1.fc7.src.rpm Update to 1.4.9 - another security update.
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.9-3.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.9-3.fc7.src.rpm * Wed Jul 25 2007 Jeffrey C. Ollie <jeff> - 1.4.9-3 - Add app_conference * Wed Jul 25 2007 Jeffrey C. Ollie <jeff> - 1.4.9-2 - Use plain useradd/groupadd rather than the fedora-usermgmt - Clean up requirements - Clean up build requirements by moving them to package sections
Hmmm... What's wrong with this bug? I have no idea why it's still not approved... Maybe some things-to-do still remains? Jeff, could you please summarize them if any?
(In reply to comment #110) > What's wrong with this bug? > I have no idea why it's still not approved... > > Maybe some things-to-do still remains? Jeff, could you please summarize them if > any? The big blocker is that the sound files that Asterisk depends on haven't had a proper license. That should be fixed "any day now" and I'm 95% certain that the license will be free enough to be included in Fedora. While the sounds aren't absolutely necessary it'd be very very difficult to do without them. If Digium's license for the sounds isn't free enough it may be necessary to re-record the sounds, perhaps initially using the OpenPBX/CallWeaver sounds as a base to start from. The other blocker is that no one has been interested enough to do a review - David Woodhouse initially indicated interest but once OpenPBX.org/CallWeaver was included he lost interest. However, there is a new proposal to set up an Asterisk server for the Fedora Project[1] so that conference calls can be run. Dennis Gilmore indicated yesterday on IRC that he would be taking over the review. Over the next few days I'll be reviewing all of the comments to make sure that I have addressed all of the concerns raised so far. [1] http://fedoraproject.org/wiki/Infrastructure/RFR/AsteriskServerInstance
(In reply to comment #111) > Dennis Gilmore indicated yesterday on IRC that he would be taking over the review. If he doesn't, I will (once the license issue with the sounds is resolved). Right now, without the sounds, the package is just a bit too broken for me to approve it.
(In reply to comment #112) > > Right now, without the sounds, the package is just a bit too broken for me to > approve it. I do have packages for the sounds available, just waiting for the license issue to be resolved to open up review tickets.
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.9-5.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.9-5.fc7.src.rpm * Fri Jul 27 2007 Jeffrey C. Ollie <jeff> - 1.4.9-5 - Update patches so we don't need to run auto* tools, because autoconf 2.60 is required and FC-6 and RHEL5 only have autoconf 2.59. * Thu Jul 26 2007 Jeffrey C. Ollie <jeff> - 1.4.9-4 - Don't build app_mp3
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.9-7.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.9-7.fc7.src.rpm * Tue Aug 7 2007 Jeffrey C. Ollie <jeff> - 1.4.9-7 - Add a patch that allows alternate extensions to be defined in users.conf * Mon Aug 6 2007 Jeffrey C. Ollie <jeff> - 1.4.9-6 - Update app_conference patch. Enter/leave sounds are now possible.
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.10-1.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.10-1.fc7.src.rpm * Tue Aug 7 2007 Jeffrey C. Ollie <jeff> - 1.4.10-1 - Update to 1.4.10 (security update). http://downloads.digium.com/pub/asa/ASA-2007-019.pdf
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.11-1.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.11-1.fc7.src.rpm * Wed Aug 22 2007 Jeffrey C. Ollie <jeff> - 1.4.11-1 - Update to 1.4.11 * Fri Aug 10 2007 Jeffrey C. Ollie <jeff> - 1.4.10.1-1 - Update to 1.4.10.1.
Does the rxfax or tffax application work for you? I hear only silence when fax call is received or sent.
(In reply to comment #118) > Does the rxfax or tffax application work for you? I hear only silence when fax > call is received or sent. I have not used Rx/TxFAX in a while. Other than suggesting you use the latest possible SpanDSP (0.0.4pre6 is in updates-testing for F-7 and 0.0.4pre7 should be available soon). Other than that I would suggest using the Asterisk IRC channels or mailing lists to help resolve the problem. If there's a problem that can be fixed with a patch I'll try and get an updated version out ASAP.
I am using spandsp-0.0.4-0.3.pre7.fc7 from Koji. This is my answer on IRC: rxfax/txfax are real problems on 1.4 :(
(In reply to comment #120) > I am using spandsp-0.0.4-0.3.pre7.fc7 from Koji. > > This is my answer on IRC: rxfax/txfax are real problems on 1.4 That's too bad... Did they give any reasons/hope? I put rxfax/txfax into my package hoping that they'd be useful for someone but if they aren't useful at all I might as well remove them.
Please, leave them here. I will test it periodically, if it is not fixed. The problem can be also in spandsp.
(In reply to comment #113) > I do have packages for the sounds available, just waiting for the license issue > to be resolved to open up review tickets. Any luck there? I have an opportunity to do some review/testing this weekend. (I have a new server to configure.)
(In reply to comment #123) > (In reply to comment #113) > > I do have packages for the sounds available, just waiting for the license issue > > to be resolved to open up review tickets. > > Any luck there? The last I heard was that the original voice talent was having issues with licensing the sounds under a completely open license. I believe that the main issue is that they didn't want the sounds being used in a non-telephony commercial context (e.g. a TV commercial) because that's how they keep food on their families tables. I can understand their concerns but unfortunately commercial use restrictions like that make it impossible to include the sounds in Fedora. I'll ping my contact @ Digium and see if there has been any movement lately.
Maybe we should just give up and come up with a asterisk-sounds-free package that contains festival-generated replacement sounds or something...
It can't be _that_ hard to do it, surely? The CallWeaver folks have already rerecorded it all, haven't they?
(In reply to comment #125) > Maybe we should just give up and come up with a asterisk-sounds-free package > that contains festival-generated replacement sounds or something... (In reply to comment #126) > It can't be _that_ hard to do it, surely? The CallWeaver folks have already > rerecorded it all, haven't they? If we used the same voice artist that the CallWeaver folks used it'd just be a matter of getting the sounds that have changed or were added after CallWeaver was forked from Asterisk.
1.4.12 released
(In reply to comment #128) > 1.4.12 released Yep, saw the announcement but I probably won't have time to build it until this weekend. I didn't see any security-related fixes in the release notes.
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5358
Spec: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.13-1.fc7.spec SRPM: http://repo.ocjtech.us/misc/fedora/7/SRPMS/asterisk-1.4.13-1.fc7.src.rpm
(In reply to comment #122) > Please, leave them here. I will test it periodically, if it is not fixed. > > The problem can be also in spandsp. > You can remove your fax support now. These patches looks to be obsolete. Anybody can compile asterisk-agx-addons, which are working well. They do not require to patch asterisk and can be built on your packages. http://www.voip-info.org/wiki/view/AGX+Extra+Addons+for+Asterisk Only one thing is a problem for me to build an official fedora rpm. There is no information about license version (only a "GPL license without a disclaimer" is mentioned).
Can you create an Fedora 8 repository? :-) Thank you.
Kevin has the fedora-review flag set to ?, but the bug is assigned to David (both since over a year ago, I gather). Is either of you or anyone else actively planning to review this package? This bug is beginning to look like an update notification channel for a package in a 3rd party repo. There obviously is interest, so why not review it and get it into Fedora?
> There obviously is interest, so why not review it and get it into Fedora? ....and EPEL eventually. Fedora is just a step on that road.
(In reply to comment #135) > > There obviously is interest, so why not review it and get it into Fedora? > > ....and EPEL eventually. Fedora is just a step on that road. I have the packages building on CentOS 5, there are a couple of Fedora packages that need to be branched/updated though.
> I have the packages building on CentOS 5, Have you tried that on centos4 too?
(In reply to comment #137) > > I have the packages building on CentOS 5, > > Have you tried that on centos4 too? I don't have any CentOS 4 systems, so I haven't.
Use mock as it comes with a centos/epel config file supplied I found I couldn't build for el5 due to the requirement for autoconf >= 2.60 when el5 comes with 2.59
(In reply to comment #139) > Use mock as it comes with a centos/epel config file supplied Yes, I have mock as well. I just don't have any RHEL4/CentOS4 systems in use so I didn't try building under mock. > I found I couldn't build for el5 due to the requirement for autoconf >= 2.60 > when el5 comes with 2.59 I have a newer package under development that doesn't require autoconf during the build, so that's not a problem. Asterisk 1.4.14 was released yesterday so I hope to have new packages uploaded this weekend. There are a couple of other problematic packages, notably speex. speex is at version 1.0 in the base RHEL/CentOS package set but speex 1.2beta is needed for the build.
I'm willing to test and report problems if you build it for epel4. there are lot of those installations out there for long time.
Spec: http://repo.ocjtech.us/misc/fedora/8/SRPMS/asterisk-1.4.14-1.fc8.spec SRPM: http://repo.ocjtech.us/misc/fedora/8/SRPMS/asterisk-1.4.14-1.fc8.src.rpm Update to 1.4.14...
[dennis@bratac ~]$ rpmlint /var/lib/mock/fedora-8-x86_64/result/* asterisk.src: W: invalid-license GPL asterisk.x86_64: E: non-standard-uid /var/spool/asterisk/tmp asterisk asterisk.x86_64: E: non-standard-gid /var/spool/asterisk/tmp asterisk asterisk.x86_64: E: non-standard-dir-perm /var/spool/asterisk/tmp 0750 asterisk.x86_64: E: non-standard-uid /var/lib/asterisk asterisk asterisk.x86_64: E: non-standard-gid /var/lib/asterisk asterisk asterisk.x86_64: E: non-standard-dir-perm /var/lib/asterisk 0750 asterisk.x86_64: E: non-standard-uid /var/log/asterisk/cdr-custom asterisk asterisk.x86_64: E: non-standard-gid /var/log/asterisk/cdr-custom asterisk asterisk.x86_64: E: non-standard-dir-perm /var/log/asterisk/cdr-custom 0750 asterisk.x86_64: E: non-standard-uid /var/spool/asterisk asterisk asterisk.x86_64: E: non-standard-gid /var/spool/asterisk asterisk asterisk.x86_64: E: non-standard-dir-perm /var/spool/asterisk 0750 asterisk.x86_64: E: non-standard-uid /var/spool/asterisk/voicemail asterisk asterisk.x86_64: E: non-standard-gid /var/spool/asterisk/voicemail asterisk asterisk.x86_64: E: non-standard-dir-perm /var/spool/asterisk/voicemail 0750 asterisk.x86_64: E: non-standard-uid /var/spool/asterisk/outgoing asterisk asterisk.x86_64: E: non-standard-gid /var/spool/asterisk/outgoing asterisk asterisk.x86_64: E: non-standard-dir-perm /var/spool/asterisk/outgoing 0770 asterisk.x86_64: E: non-standard-uid /var/log/asterisk/cdr-csv asterisk asterisk.x86_64: E: non-standard-gid /var/log/asterisk/cdr-csv asterisk asterisk.x86_64: E: non-standard-dir-perm /var/log/asterisk/cdr-csv 0750 asterisk.x86_64: E: non-standard-uid /var/run/asterisk asterisk asterisk.x86_64: E: non-standard-gid /var/run/asterisk asterisk asterisk.x86_64: E: non-standard-uid /var/log/asterisk asterisk asterisk.x86_64: E: non-standard-gid /var/log/asterisk asterisk asterisk.x86_64: E: non-standard-dir-perm /var/log/asterisk 0750 asterisk.x86_64: W: incoherent-version-in-changelog 1.4.13-7 1.4.14-1.fc8 asterisk.x86_64: W: invalid-license GPL asterisk-alsa.x86_64: W: no-documentation asterisk-alsa.x86_64: W: invalid-license GPL asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__speech__result__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structjb__frame__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__db__entry__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__state__cb__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/ie_8c__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structiax2__context__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__key__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__ha__coll__graph.map asterisk-apidoc.x86_64: W: file-not-utf8 /usr/share/doc/asterisk-apidoc-1.4.14/html/fskmodem_8c.html asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/sha1_8h__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structrobin__list__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__config__map__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structeventqent__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/isdn__lib_8h__incl.map asterisk-apidoc.x86_64: W: file-not-utf8 /usr/share/doc/asterisk-apidoc-1.4.14/html/fskmodem_8h.html asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/pbx__kdeconsole_8h__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structargapp__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structiax__template__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__comment__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/gentone-ulaw_8c__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structdlstatus__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structfixed__jb__frame__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structmgcp__request__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structmanager__action__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structiax2__dpcache__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structenum__search__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structevent__node__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__cli__entry__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__cdr__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__http__uri__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structosp__provider__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structmgcp__response__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structtone__zone__sound__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structiax2__trunk__peer__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/gentone_8c__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structnodelog__coll__graph.map asterisk-apidoc.x86_64: W: file-not-utf8 /usr/share/doc/asterisk-apidoc-1.4.14/html/fskmodem_8c-source.html asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structsip__route__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structsip__auth__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__config__engine__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structagi__command__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structmsn__list__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__ignorepat__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structast__string__field__pool__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.14/html/structgtalk__candidate__coll__graph.map asterisk-apidoc.x86_64: W: invalid-license GPL asterisk-conference.x86_64: W: invalid-license GPL asterisk-curl.x86_64: W: no-documentation asterisk-curl.x86_64: W: invalid-license GPL asterisk-debuginfo.x86_64: W: invalid-license GPL asterisk-devel.x86_64: W: invalid-license GPL asterisk-fax.x86_64: W: no-documentation asterisk-fax.x86_64: W: invalid-license GPL asterisk-festival.x86_64: W: no-documentation asterisk-festival.x86_64: W: invalid-license GPL asterisk-firmware.x86_64: W: no-documentation asterisk-jabber.x86_64: W: invalid-license GPL asterisk-misdn.x86_64: W: summary-not-capitalized mISDN channel for Asterisk asterisk-misdn.x86_64: W: invalid-license GPL asterisk-mobile.x86_64: W: invalid-license GPL asterisk-odbc.x86_64: W: no-documentation asterisk-odbc.x86_64: W: invalid-license GPL asterisk-oss.x86_64: W: no-documentation asterisk-oss.x86_64: W: invalid-license GPL asterisk-postgresql.x86_64: W: no-documentation asterisk-postgresql.x86_64: W: invalid-license GPL asterisk-radius.x86_64: W: invalid-license GPL asterisk-skinny.x86_64: W: no-documentation asterisk-skinny.x86_64: W: invalid-license GPL asterisk-snmp.x86_64: W: invalid-license GPL asterisk-tds.x86_64: W: invalid-license GPL asterisk-voicemail.x86_64: W: no-documentation asterisk-voicemail.x86_64: W: invalid-license GPL asterisk-voicemail-imap.x86_64: W: invalid-license GPL asterisk-voicemail-odbc.x86_64: E: summary-too-long Voicemail implementation for Asterisk that uses ODBC to store voicemail in a database asterisk-voicemail-odbc.x86_64: E: description-line-too-long Voicemail implementation for Asterisk that uses ODBC to store voicemail in a database. asterisk-voicemail-odbc.x86_64: W: invalid-license GPL asterisk-voicemail-plain.x86_64: W: no-documentation asterisk-voicemail-plain.x86_64: E: summary-too-long Voicemail implementation for Asterisk that stores voicemail on the local filesystem asterisk-voicemail-plain.x86_64: E: description-line-too-long Voicemail implementation for Asterisk that stores voicemail on the local filesystem asterisk-voicemail-plain.x86_64: W: invalid-license GPL asterisk-zaptel.x86_64: W: no-documentation asterisk-zaptel.x86_64: W: invalid-license GPL ok so the license needs clarification all the empty doc files should go package builds in mock the non standard uid's and gid's are ok.
SQL injection vulnerabilities in < 1.4.15: http://www.asterisk.org/node/48429 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6170 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6171
Spec: http://repo.ocjtech.us/misc/fedora/8/SRPMS/asterisk-1.4.15-1.fc8.spec SRPM: http://repo.ocjtech.us/misc/fedora/8/SRPMS/asterisk-1.4.15-1.fc8.src.rpm * Fri Nov 30 2007 Jeffrey C. Ollie <jeff> - 1.4.15-1 * Update to 1.4.15 (security fixes) * Tue Nov 20 2007 Jeffrey C. Ollie <jeff> - 1.4.14-2 * Fix license and other rpmlint warnings.
An error occurred while loading http://repo.ocjtech.us/misc/fedora/8/SRPMS/asterisk-1.4.15-1.fc8.src.rpm: Could not connect to host repo.ocjtech.us.
(In reply to comment #146) > An error occurred while loading > http://repo.ocjtech.us/misc/fedora/8/SRPMS/asterisk-1.4.15-1.fc8.src.rpm: > Could not connect to host repo.ocjtech.us. Oops... web server didn't start up when I rebooted the system. Should work now.
asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/ie_8c__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structtone__zone__sound__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/gentone-ulaw_8c__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__speech__result__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__state__cb__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structgtalk__candidate__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structevent__node__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__cli__entry__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structsip__route__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structsip__auth__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__http__uri__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structjb__frame__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structmgcp__response__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__key__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__cdr__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structmgcp__request__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structfixed__jb__frame__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/sha1_8h__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structiax2__context__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__config__map__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structdlstatus__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structiax__template__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structagi__command__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structeventqent__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__comment__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__db__entry__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structargapp__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__ha__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structmanager__action__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/gentone_8c__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structiax2__dpcache__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__string__field__pool__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structosp__provider__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structrobin__list__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structiax2__trunk__peer__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/pbx__kdeconsole_8h__incl.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structmsn__list__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__config__engine__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structast__ignorepat__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structenum__search__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/structnodelog__coll__graph.map asterisk-apidoc.x86_64: E: zero-length /usr/share/doc/asterisk-apidoc-1.4.15/isdn__lib_8h__incl.map builds fine in mock fix those empty files and ill approve asterisk
Spec: http://repo.ocjtech.us/misc/fedora/8/SRPMS/asterisk-1.4.15-2.fc8.spec SRPM: http://repo.ocjtech.us/misc/fedora/8/SRPMS/asterisk-1.4.15-2.fc8.src.rpm * Mon Dec 10 2007 Jeffrey C. Ollie <jeff> - 1.4.15-2 - Get rid of zero length map files. - Shorten descriptions of voicemail subpackages
Spec: http://repo.ocjtech.us/misc/fedora/development/SRPMS/asterisk-1.4.15-3.fc9.spec SRPM: http://repo.ocjtech.us/misc/fedora/development/SRPMS/asterisk-1.4.15-3.fc9.src.rpm * Tue Dec 11 2007 Jeffrey C. Ollie <jeff> - 1.4.15-3 - Really get rid of zero length map files.
Looks good now Approved
New Package CVS Request ======================= Package Name: asterisk Short Description: The Open Source PBX Owners: jcollie Branches: development F-8 F-7
cvs done
OK to close this review request?
comment 136 > I have the packages building on CentOS 5, there are a couple of > Fedora packages that need to be branched/updated though. Jeffrey, any status update in centos 5 repos? I could give this a try with couple cisco phones.
There's probably not going to be official packages of Asterisk for EPEL because my Asterisk packages require speex 1.2 and RHEL/CentOS has speex 1.0.5. I do have unofficial EL-5 packages because the Asterisk systems I'm running use CentOS 5: http://repo.ocjtech.us/misc/epel/5/ There are updated speex 1.2 packages there which may cause problems if you are using other packages on CentOS that have been linked against the older speex.
There is now a new release of app conference
Will Asterisk is now in Fedora please file a bug against asterisk
The app_conference is not from asterisk.org it's a 3rd part app from http://sourceforge.net/projects/appconference/ Asterisk ships with app_meetme which requires zaptel
(In reply to comment #159) > The app_conference is not from asterisk.org it's a 3rd part app from > http://sourceforge.net/projects/appconference/ > Asterisk ships with app_meetme which requires zaptel Yes, I'm aware of where app_conference came from. What Dennis meant was to file a NEW bug against the Fedora Asterisk package. Please don't add a new request like this to a bug that has been closed for several months.
(In reply to comment #156) > There are updated speex 1.2 packages there which may cause problems if you are > using other packages on CentOS that have been linked against the older speex. Is it possible add asterisk into EPEL5 *without* speex codec support?
(In reply to comment #161) > (In reply to comment #156) > > There are updated speex 1.2 packages there which may cause problems if you are > > using other packages on CentOS that have been linked against the older speex. > > Is it possible add asterisk into EPEL5 *without* speex codec support? Not really, as the speex library is used for more than just the speex codec. IIRC there are some echo cancellation and some other audio routines used.
Sorry, but how Digium built such versions? http://www.asterisk.org/downloads/yum Is they use bundled version of speex?
It looks like they build without speex support.
Is it hard to doing something similar for EPEL5?
(In reply to comment #156) > There's probably not going to be official packages of Asterisk for EPEL because > my Asterisk packages require speex 1.2 and RHEL/CentOS has speex 1.0.5. # rpm -q speex centos-release speex-1.2-0.12.rc1.1.el6.x86_64 centos-release-6-0.el6.centos.5.x86_64 I can co-maintain if we decide to compile for epel5.
(In reply to comment #156) > There's probably not going to be official packages of Asterisk for EPEL because > my Asterisk packages require speex 1.2 and RHEL/CentOS has speex 1.0.5. # rpm -q speex centos-release speex-1.2-0.12.rc1.1.el6.x86_64 centos-release-6-0.el6.centos.5.x86_64 I can co-maintain if we decide to compile for epel6.
Asterisk is already in EPEL6, and RHEL5 still has speex 1.0.5.
Yep, noticed that after digging further, unfortunately bz doesn't allow editing/removing comments in next couple hours. :-/ Asterisk is already running.