Bug 178922 - Review Request: asterisk - The Open Source PBX
Review Request: asterisk - The Open Source PBX
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dennis Gilmore
Fedora Package Reviews List
:
Depends On: 171597 177584 177603
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-25 10:09 EST by Jeffrey C. Ollie
Modified: 2011-08-05 06:20 EDT (History)
28 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-21 09:08:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dennis: fedora‑review+
dennis: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Jeffrey C. Ollie 2006-01-25 10:09:29 EST
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.
Comment 1 Gabriel Somlo 2006-01-25 13:21:23 EST
> %{_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" ?
Comment 2 Ville Skyttä 2006-01-25 14:52:44 EST
(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
Comment 3 Jeffrey C. Ollie 2006-01-26 00:52:19 EST
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@ocjtech.us> - 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@ocjtech.us> - 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@ocjtech.us> - 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.
Comment 4 Jeffrey C. Ollie 2006-01-26 00:55:11 EST
(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.
Comment 5 Rudolf Kastl 2006-01-26 06:43:30 EST
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.)
Comment 6 Rudolf Kastl 2006-01-26 06:51:41 EST
just curious... why do you "noreplace" all configs? dont we want to have the 
unmodified default configs replaced?
Comment 7 Jeffrey C. Ollie 2006-01-26 09:00:44 EST
(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.
Comment 8 Rudolf Kastl 2006-01-26 10:00:07 EST
(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.
Comment 9 Paul Howarth 2006-01-26 10:09:53 EST
(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).

Comment 10 Rudolf Kastl 2006-01-26 10:14:56 EST
> 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.
Comment 11 Jeffrey C. Ollie 2006-01-26 10:45:44 EST
(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."
Comment 12 Jeffrey C. Ollie 2006-01-31 01:21:15 EST
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@ocjtech.us> - 1.2.4-1
- Update to 1.2.4.
Comment 13 Jeffrey C. Ollie 2006-02-07 00:34:19 EST
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@ocjtech.us> - 1.2.4-2
- BR sqlite2-devel

Comment 14 Patrick 2006-02-14 01:40:05 EST
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.
Comment 15 Roy-Magne Mo 2006-02-18 20:41:34 EST
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. 
Comment 16 Jeffrey C. Ollie 2006-03-06 23:57:17 EST
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@ocjtech.us> - 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.
Comment 17 Matthias Saou 2006-03-29 07:12:53 EST
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/
Comment 18 Roy-Magne Mo 2006-04-10 08:09:01 EDT
any chance for a update to 1.2.6?
Comment 19 Jeffrey C. Ollie 2006-04-10 08:34:32 EDT
(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
Comment 20 Jeffrey C. Ollie 2006-04-10 13:14:24 EDT
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@ocjtech.us> - 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@ocjtech.us> - 1.2.6-2
- Don't build GTK 1.X console since GTK 1.X is being moved out of core...

Comment 21 Mathieu Chouquet-Stringer 2006-04-12 12:54:51 EDT
It would also be nice to include the extra sounds.
Comment 22 Mathieu Chouquet-Stringer 2006-04-12 13:00:20 EDT
Or rather in a separate rpm (I see that Matthias packages them in asterisk-sounds).
Comment 23 Matthias Saou 2006-04-12 13:04:19 EDT
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...).
Comment 24 Jeffrey C. Ollie 2006-04-12 13:10:21 EDT
(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.
Comment 25 Jeffrey C. Ollie 2006-04-12 13:16:43 EDT
(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.
Comment 26 Mathieu Chouquet-Stringer 2006-04-12 13:53:35 EDT
(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.
Comment 27 Jeffrey C. Ollie 2006-04-12 19:56:33 EDT
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
Comment 28 Matthias Saou 2006-04-13 07:03:52 EDT
> 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.
Comment 29 Mathieu Chouquet-Stringer 2006-04-13 08:00:55 EDT
(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)... ;-)
Comment 30 Jeffrey C. Ollie 2006-04-13 23:26:42 EDT
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
Comment 31 David Woodhouse 2006-04-19 13:21:28 EDT
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.
Comment 32 Jeffrey C. Ollie 2006-04-20 01:31:21 EDT
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@ocjtech.us> - 1.2.7.1-3
- Add chan_bluetooth

* Wed Apr 19 2006 Jeffrey C. Ollie <jeff@ocjtech.us> - 1.2.7.1-2
- Split off more stuff into subpackages.

Comment 33 Jeffrey C. Ollie 2006-04-20 01:43:53 EDT
(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.
Comment 34 Jeffrey C. Ollie 2006-04-20 10:45:21 EDT
(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.
Comment 35 Rudolf Kastl 2006-04-20 13:44:23 EDT
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.
Comment 36 David Woodhouse 2006-04-24 07:02:49 EDT
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
Comment 37 Jeffrey C. Ollie 2006-04-24 12:45:37 EDT
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.
Comment 38 David Woodhouse 2006-04-24 15:42:04 EDT
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.
Comment 39 Jeffrey C. Ollie 2006-04-24 23:12:45 EDT
(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.
Comment 40 Roy-Magne Mo 2006-04-29 18:50:48 EDT
(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?
Comment 41 Jeffrey C. Ollie 2006-05-01 15:39:51 EDT
(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.

Comment 42 Dennis Gilmore 2006-05-02 15:02:40 EDT
Should the zaptel subpackage  really obsolete the sqlite subpackage?  
Comment 43 Jeffrey C. Ollie 2006-05-02 15:36:20 EDT
(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@ocjtech.us> - 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@ocjtech.us> - 1.2.7.1-5
- Build mISDN channel drivers, modelled after spec file from David Woodhouse

* Thu Apr 20 2006 Jeffrey C. Ollie <jeff@ocjtech.us> - 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.
Comment 44 Roy-Magne Mo 2006-05-07 15:05:05 EDT
(In reply to comment #43)
> %changelog
> * Tue May  2 2006 Jeffrey C. Ollie <jeff@ocjtech.us> - 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 :) 
Comment 45 Ville Skyttä 2006-06-08 12:48:15 EDT
Security: http://www.asterisk.org/node/95
Comment 46 Jeffrey C. Ollie 2006-06-08 13:09:37 EDT
(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.
Comment 47 Jeffrey C. Ollie 2006-06-08 16:18:55 EDT
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/
Comment 48 Roy-Magne Mo 2006-07-25 09:07:49 EDT
any chance for a update to 1.2.10 for asterisk? 
Comment 50 Reuben Farrelly 2006-08-17 03:05:42 EDT
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?
Comment 51 Gianluca Sforna 2006-08-17 06:24:54 EDT
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

Comment 52 Ville Skyttä 2006-08-24 18:20:23 EDT
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
Comment 53 David Woodhouse 2006-08-31 12:17:26 EDT
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.
Comment 54 David Woodhouse 2006-08-31 13:01:29 EDT
Should we be using sqlite2 instead of 'sqlite' which is sqlite v3?
Comment 55 David Woodhouse 2006-09-01 19:47:11 EDT
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.
Comment 56 David Woodhouse 2006-09-01 20:04:30 EDT
Start of POSIX timer stuff here:
http://lists.digium.com/pipermail/asterisk-dev/2005-May/012906.html

pselect() does work now.
Comment 57 Kevin Fenzi 2006-09-01 22:50:24 EDT
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? :) 
Comment 58 David Woodhouse 2006-09-01 23:28:54 EDT
Yes, that's the plan.
Comment 59 David Woodhouse 2006-10-02 18:54:04 EDT
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.
Comment 60 David Woodhouse 2006-10-02 19:56:18 EDT
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.
Comment 61 Jeffrey C. Ollie 2006-10-03 00:26:53 EDT
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.
Comment 62 David Woodhouse 2006-10-03 04:08:40 EDT
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.
Comment 63 Jeffrey C. Ollie 2006-10-17 23:20:19 EDT
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@ocjtech.us> - 1.4.0-0.beta2
- Update to 1.4.0-beta2

Comment 65 Jeffrey C. Ollie 2006-10-19 01:36:55 EDT
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@lt21223.campus.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@ocjtech.us> - 1.4.0-2.beta3
- Remove requirement on asterisk-sounds-core until licensing can be
  figured out.
Comment 66 David Woodhouse 2006-10-19 05:43:29 EDT
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

Comment 67 Jeffrey C. Ollie 2006-10-19 08:15:27 EDT
(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.



Comment 68 Jeffrey C. Ollie 2006-10-19 08:19:00 EDT
(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.
Comment 69 Jeffrey C. Ollie 2006-10-19 08:31:29 EDT
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.

Comment 70 David Woodhouse 2006-10-19 08:42:16 EDT
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.
Comment 71 Jeffrey C. Ollie 2006-10-20 16:35:05 EDT
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@ocjtech.us> - 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@ocjtech.us> - 1.4.0-4.beta3
- Remove explicit dependency on glibc-kernheaders.
- Add patch to remove linux/compiler.h dependency.
- Build jabber modules on PPC
Comment 72 Jeffrey C. Ollie 2006-12-18 19:12:09 EST
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@ocjtech.us> - 1.4.0-6.beta4
- Update to 1.4.0-beta4
- Various cleanups.

Comment 73 Steven Pritchard 2006-12-31 15:38:03 EST
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...  :-)
Comment 74 Steven Pritchard 2006-12-31 15:43:30 EST
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.
Comment 75 Steven Pritchard 2006-12-31 18:19:10 EST
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.
Comment 76 Jeffrey C. Ollie 2007-01-01 21:26:45 EST
1.4 final shouldn't be that different from the last beta.  Hopefully I'll have
new SRPMS up in a day or so.
Comment 77 Steven Pritchard 2007-01-02 16:20:28 EST
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.
Comment 78 Steven Pritchard 2007-01-03 14:14:33 EST
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?)
Comment 79 Jeffrey C. Ollie 2007-01-03 14:34:31 EST
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.
Comment 80 David Woodhouse 2007-01-03 15:52:14 EST
OpenPBX sounds are OK though -- can we use those? 
Comment 81 Jeffrey C. Ollie 2007-01-03 16:04:58 EST
(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.
Comment 82 Hans de Goede 2007-03-05 03:54:59 EST
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.

Comment 83 Jeffrey C. Ollie 2007-03-06 01:25:24 EST
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@ocjtech.us> - 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.

Comment 84 Jeffrey C. Ollie 2007-03-08 16:41:38 EST
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@ocjtech.us> - 1.4.1-2
- Package the IAXy firmware
- Minor clean-ups in files
Comment 86 Jeffrey C. Ollie 2007-03-23 22:53:45 EDT
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...
Comment 87 Jeffrey C. Ollie 2007-04-25 20:12:58 EDT
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.
Comment 89 Ville Skyttä 2007-05-09 14:47:45 EDT
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."
Comment 90 Jeffrey C. Ollie 2007-05-10 00:50:42 EDT
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@ocjtech.us> - 1.4.4-2
- Add a patch to fix CVE-2007-2488/ASA-2007-013
Comment 91 Matthias Saou 2007-05-17 03:50:29 EDT
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.
Comment 92 Stefan van der Eijk 2007-05-22 04:30:22 EDT
The Mandriva asterisk packages run as non-root. Feel free to check & see how
they did it.
Comment 93 Kevin Fenzi 2007-05-30 23:38:44 EDT
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@fedoraproject.org so someone else could move it forward?
Comment 94 Itamar Reis Peixoto 2007-06-13 00:01:08 EDT
where are asterisk-addons to use mysql cdr support ?

Comment 95 Jeffrey C. Ollie 2007-06-13 09:51:26 EDT
(In reply to comment #94)
> where are asterisk-addons to use mysql cdr support ?

I have not packaged asterisk-addons.
Comment 96 Itamar Reis Peixoto 2007-06-14 16:43:31 EDT
(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.
Comment 97 Itamar Reis Peixoto 2007-06-14 16:46:44 EDT
(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.
Comment 98 Jeffrey C. Ollie 2007-06-14 17:23:54 EDT
(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.
Comment 100 Jeffrey C. Ollie 2007-06-19 12:04:28 EDT
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@ocjtech.us> - 1.4.5-9
- Move sounds

* Mon Jun 18 2007 Jeffrey C. Ollie <jeff@ocjtech.us> - 1.4.5-8
- Update some more ownership/permissions

* Mon Jun 18 2007 Jeffrey C. Ollie <jeff@ocjtech.us> - 1.4.5-7
- Fix some permissions.

* Mon Jun 18 2007 Jeffrey C. Ollie <jeff@ocjtech.us> - 1.4.5-6
- Update init script patch
- Move pid file to subdir of /var/run

* Mon Jun 18 2007 Jeffrey C. Ollie <jeff@ocjtech.us> - 1.4.5-5
- Update init script patch to run as non-root

* Sun Jun 17 2007 Jeffrey C. Ollie <jeff@ocjtech.us> - 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@ocjtech.us> - 1.4.5-3
- Have the build output the commands executing, rather than covering them up.
Comment 101 Jeffrey C. Ollie 2007-06-19 12:37:37 EDT
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
Comment 102 Jeffrey C. Ollie 2007-06-20 16:48:13 EDT
Response from Digium about license for sounds:

http://lists.digium.com/pipermail/asterisk-dev/2007-June/028176.html
Comment 103 Jeffrey C. Ollie 2007-06-22 16:00:31 EDT
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@ocjtech.us> - 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.

Comment 107 Jeffrey C. Ollie 2007-07-18 01:07:27 EDT
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.



Comment 108 Jeffrey C. Ollie 2007-07-25 15:23:01 EDT
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.
Comment 109 Jeffrey C. Ollie 2007-07-26 01:08:51 EDT
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@ocjtech.us> - 1.4.9-3
- Add app_conference

* Wed Jul 25 2007 Jeffrey C. Ollie <jeff@ocjtech.us> - 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
Comment 110 Peter Lemenkov 2007-07-26 03:15:53 EDT
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?
Comment 111 Jeffrey C. Ollie 2007-07-26 10:19:59 EDT
(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
Comment 112 Steven Pritchard 2007-07-26 10:45:41 EDT
(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.
Comment 113 Jeffrey C. Ollie 2007-07-26 11:42:15 EDT
(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.
Comment 114 Jeffrey C. Ollie 2007-07-29 13:42:45 EDT
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@ocjtech.us> - 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@ocjtech.us> - 1.4.9-4
- Don't build app_mp3

Comment 115 Jeffrey C. Ollie 2007-08-07 17:25:22 EDT
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@ocjtech.us> - 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@ocjtech.us> - 1.4.9-6
- Update app_conference patch. Enter/leave sounds are now possible.
Comment 117 Jeffrey C. Ollie 2007-08-23 13:01:26 EDT
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@ocjtech.us> - 1.4.11-1
- Update to 1.4.11

* Fri Aug 10 2007 Jeffrey C. Ollie <jeff@ocjtech.us> - 1.4.10.1-1
- Update to 1.4.10.1.
Comment 118 Jan ONDREJ 2007-08-27 03:08:36 EDT
Does the rxfax or tffax application work for you? I hear only silence when fax
call is received or sent.
Comment 119 Jeffrey C. Ollie 2007-08-27 08:34:38 EDT
(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.
Comment 120 Jan ONDREJ 2007-08-27 09:27:45 EDT
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

:(
Comment 121 Jeffrey C. Ollie 2007-08-27 09:41:05 EDT
(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.
Comment 122 Jan ONDREJ 2007-08-27 11:40:09 EDT
Please, leave them here. I will test it periodically, if it is not fixed.

The problem can be also in spandsp.
Comment 123 Steven Pritchard 2007-09-21 10:08:31 EDT
(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.)
Comment 124 Jeffrey C. Ollie 2007-09-21 10:26:45 EDT
(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.  
Comment 125 Steven Pritchard 2007-09-21 11:43:46 EDT
Maybe we should just give up and come up with a asterisk-sounds-free package
that contains festival-generated replacement sounds or something...
Comment 126 David Woodhouse 2007-09-21 11:47:35 EDT
It can't be _that_ hard to do it, surely? The CallWeaver folks have already
rerecorded it all, haven't they?
Comment 127 Jeffrey C. Ollie 2007-09-21 12:08:34 EDT
(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.  
Comment 128 Itamar Reis Peixoto 2007-10-04 15:34:12 EDT
1.4.12 released
Comment 129 Jeffrey C. Ollie 2007-10-04 20:45:07 EDT
(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.
Comment 130 Ville Skyttä 2007-10-15 11:50:35 EDT
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5358
Comment 132 Jan ONDREJ 2007-11-13 12:28:21 EST
(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).
Comment 133 Jan ONDREJ 2007-11-13 12:31:22 EST
Can you create an Fedora 8 repository? :-)
Thank you.
Comment 134 Ville Skyttä 2007-11-13 13:53:09 EST
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?
Comment 135 Juha Tuomala 2007-11-16 08:35:06 EST
> 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.
Comment 136 Jeffrey C. Ollie 2007-11-16 09:37:16 EST
(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.
Comment 137 Juha Tuomala 2007-11-16 09:57:46 EST
> I have the packages building on CentOS 5,

Have you tried that on centos4 too?
Comment 138 Jeffrey C. Ollie 2007-11-16 10:02:56 EST
(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.
Comment 139 Will Tatam 2007-11-17 11:07:59 EST
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
Comment 140 Jeffrey C. Ollie 2007-11-17 12:13:38 EST
(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.
Comment 141 Juha Tuomala 2007-11-17 12:23:01 EST
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.
Comment 143 Dennis Gilmore 2007-11-20 11:12:25 EST
[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.
Comment 145 Jeffrey C. Ollie 2007-12-10 17:20:50 EST
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@ocjtech.us> - 1.4.15-1
* Update to 1.4.15 (security fixes)

* Tue Nov 20 2007 Jeffrey C. Ollie <jeff@ocjtech.us> - 1.4.14-2
* Fix license and other rpmlint warnings.
Comment 146 Dennis Gilmore 2007-12-10 17:39:26 EST
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.
Comment 147 Jeffrey C. Ollie 2007-12-10 21:12:09 EST
(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.
Comment 148 Dennis Gilmore 2007-12-10 22:54:16 EST
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
Comment 149 Jeffrey C. Ollie 2007-12-11 11:16:01 EST
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@ocjtech.us> - 1.4.15-2
- Get rid of zero length map files.
- Shorten descriptions of voicemail subpackages
Comment 150 Jeffrey C. Ollie 2007-12-11 21:18:54 EST
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@ocjtech.us> - 1.4.15-3
- Really get rid of zero length map files.
Comment 151 Dennis Gilmore 2007-12-11 21:27:45 EST
Looks good now Approved
Comment 152 Jeffrey C. Ollie 2007-12-11 22:00:04 EST
New Package CVS Request
=======================
Package Name: asterisk
Short Description: The Open Source PBX
Owners: jcollie
Branches: development F-8 F-7
Comment 153 Dennis Gilmore 2007-12-11 23:44:40 EST
cvs done
Comment 154 Peter Lemenkov 2007-12-21 09:00:19 EST
OK to close this review request?
Comment 155 Juha Tuomala 2007-12-21 09:35:52 EST
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.
Comment 156 Jeffrey C. Ollie 2007-12-21 10:21:46 EST
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.
Comment 157 Will Tatam 2008-02-28 09:18:06 EST
There is now a new release of app conference
Comment 158 Dennis Gilmore 2008-02-28 10:42:29 EST
Will Asterisk is now in Fedora  please file a bug against asterisk 
Comment 159 Will Tatam 2008-02-28 12:04:06 EST
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
Comment 160 Jeffrey C. Ollie 2008-02-28 12:08:56 EST
(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.
Comment 161 Pavel Alexeev 2011-02-21 04:58:05 EST
(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?
Comment 162 Jeffrey C. Ollie 2011-02-21 15:00:11 EST
(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.
Comment 163 Pavel Alexeev 2011-02-22 03:56:10 EST
Sorry, but how Digium built such versions? http://www.asterisk.org/downloads/yum
Is they use bundled version of speex?
Comment 164 Jeffrey C. Ollie 2011-02-22 10:39:33 EST
It looks like they build without speex support.
Comment 165 Pavel Alexeev 2011-02-23 13:33:54 EST
Is it hard to doing something similar for EPEL5?
Comment 166 Juha Tuomala 2011-08-03 08:11:17 EDT
(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.
Comment 167 Juha Tuomala 2011-08-03 08:11:31 EDT
(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.
Comment 168 Jeffrey C. Ollie 2011-08-04 09:01:17 EDT
Asterisk is already in EPEL6, and RHEL5 still has speex 1.0.5.
Comment 169 Juha Tuomala 2011-08-05 06:15:18 EDT
Yep, noticed that after digging further, unfortunately bz doesn't allow editing/removing comments in next couple hours. :-/ Asterisk is already running.

Note You need to log in before you can comment on or make changes to this bug.