<div class="gmail_quote">2009/3/28 Jason Parker <span dir="ltr"><<a href="mailto:jparker@digium.com">jparker@digium.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
D Tucny wrote:<br>
> 2009/3/26 John Morris <<a href="mailto:asterisk@zultron.com">asterisk@zultron.com</a> <mailto:<a href="mailto:asterisk@zultron.com">asterisk@zultron.com</a>>><br>
<div class="im">><br>
> Hi, Axel.<br>
><br>
> Axel Thimm wrote:<br>
> > How about merging in your changes/improvements/new packages with<br>
> > ATrpms (and automatically later into <a href="http://rpmrepo.org" target="_blank">rpmrepo.org</a><br>
</div>> <<a href="http://rpmrepo.org" target="_blank">http://rpmrepo.org</a>>)? That way we won't<br>
<div class="im">> > have further fragmentation and a larger user base to test bits (which<br>
> > will be distributed in stable, testing etc repos).<br>
><br>
> Of course I'd love to contribute my changes to ATrpms. Some of the<br>
> small changes I made, such as adding OSLEC to the DAHDI RPMs, might be<br>
> nice for ATrpms users. I'll whip up some patches against the ATrpms<br>
> sources.<br>
><br>
> My problem with ATrpms, though, is that the RPMs make use of many custom<br>
> macros that make them unbuildable outside the ATrpms environment. I<br>
> understand that might be necessary for RPMs like DAHDI that build kernel<br>
> modules for several versions of several distros, where vanilla specfile<br>
> code would get hairy. (I think we had this discussion a couple of years<br>
> ago on the ATrpms ML.) Since I don't have to worry about multiple<br>
> versions of multiple distros in my environment, I prefer to use vanilla<br>
> specfile that will rebuild on anyone's CentOS 5 system.<br>
><br>
><br>
> Alternatively, there's also the RPMS at<br>
> <a href="http://packages.asterisk.org/centos/" target="_blank">http://packages.asterisk.org/centos/</a> which seem to have a nice spread of<br>
> options available, including 1.4/1.6 packages, are pretty nicely<br>
> modularised and seem to be kept pretty fresh... They do however seem to<br>
> have some issues that your RPMS (and Axel's) don't (e.g. why wouldn't an<br>
> init file be included? and where's the changelog?)... Perhaps it would<br>
> be useful to help the digium packager build some better packages... That<br>
> would also help with reducing fragmentation, if there were decent<br>
> quality 'official' packages available then it would save the time and<br>
</div>> effort Axel and the <a href="http://rpmrepo.org" target="_blank">rpmrepo.org</a> <<a href="http://rpmrepo.org" target="_blank">http://rpmrepo.org</a>> folks too as they<br>
<div class="im">> could in theory base any extras on those packages rather than needing to<br>
> maintain the entire set...<br>
><br>
> d<br>
><br>
<br>
</div>As the author of the RPMs at <a href="http://packages.asterisk.org/" target="_blank">http://packages.asterisk.org/</a> (as well as<br>
<a href="http://packages.digium.com/" target="_blank">http://packages.digium.com/</a>), and the maintainer of the repositories, I wanted<br>
to respond to this.<br>
<br>
I would love it if some of this were to happen. I am very familiar with Axel<br>
and ATrpms - he has proven countless times that he knows what he's doing when it<br>
comes to this sort of thing. Getting help/advice from somebody like him would<br>
be extremely beneficial. As far as basing the ATrpms (or others) packages on<br>
the AsteriskNOW packages, if that is something that Axel (or others) wanted to<br>
do, I would be more than willing to help with whatever is needed. On a somewhat<br>
related, and very interesting note - I found out yesterday that the latest<br>
trixbox beta is using these RPMs (without even needing to rebuild them, in some<br>
cases). Hopefully that means I'm doing something right.<br>
<br>
D, the two issues you brought up are valid. For the Asterisk RPMs, I honestly<br>
don't know why there isn't an init script - I actually thought there was one.<br>
FreePBX is what starts Asterisk in AsteriskNOW, so it was easily overlooked. It<br>
will be there in future builds. </blockquote><div><br>Cool... I tried the 1.6 packages out a couple of days ago, not using FreePBX, the biggest issue I've found so far was the lack of init scripts, both in the asterisk packages and the dahdi... I'll have a look at patching the spec's to make them more usable without freepbx and feed back to you...<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As far as the changelog, it was one of those<br>
things that I intentionally left out for a while, and I kept meaning to "do it<br>
later". Really, it's because I'm not sure what should go into an RPM changelog<br>
(I'd love to hear from anybody that has any insight into that).<br>
</blockquote><div><br>What would typically go in an RPM changelog (as with most changelogs) is a note associated with each revision... <br><br>e.g. for the asterisk16 RPM you may have something like this (which I knocked up from looking at the specs for each release) that makes it simple to see why there is a new revision without having to dig through the SRPMs...<br>
<br>%changelog<br><br>* Sat Mar 21 2009 Jason Parker <<a href="mailto:jparker@digium.com">jparker@digium.com</a>> - 1.6.0.6-2<br>- specify asterisk:asterisk ownership and specific permissions of directories and files that should be writable at runtime<br>
<br>* Tue Feb 24 2009 Jason Parker <<a href="mailto:jparker@digium.com">jparker@digium.com</a>> - 1.6.0.6-1<br>- Update to 1.6.0.6<br>- add astapi variable and add provides with that variable for each child package<br>
- include func_audiohookinherit.so, aelparse and conf2ael<br>- change useradd to use '-r' to create a system account with UID below UID_MIN and produce no output<br><br>* Wed Feb 11 2009 Jason Parker <<a href="mailto:jparker@digium.com">jparker@digium.com</a>> - 1.6.0.5-1<br>
- Update to 1.6.0.5<br>- add distname and distver variables to allow logic for building on other dists<br>- add logic to modify buildreqs and reqs if building for suse/sles<br>- make newt buildreq optional (without_newt)<br>
- include odbcstorage and imapstorage in splitopts patch<br><br>* Wed Nov 12 2008 Jason Parker <<a href="mailto:jparker@digium.com">jparker@digium.com</a>> - 1.6.0.1-3<br>- Change from linking to copying odbcstorage and imapstorage voicemail modules<br>
- Change config option to noreplace to avoid overwriting modified configs<br><br>* Mon Oct 13 2008 Jason Parker <<a href="mailto:jparker@digium.com">jparker@digium.com</a>> - 1.6.0.1-2<br>- Added resample subpackage<br>
<br>* Thu Oct 9 2008 Jason Parker <<a href="mailto:jparker@digium.com">jparker@digium.com</a>> - 1.6.0.1-1<br>- Initial 1.6 build.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
As always, if anybody has any ideas, suggestions, criticism, or any other type<br>
of feedback, I'd be happy to hear from you.<br>
<div></div></blockquote><div><br></div></div>I hope this helps... I'll drop more feedback to you directly at some point and hopefully John, Axel, Tzafrir and others will do the same...<br><br>d<br>