John Morris
2009-Mar-25 16:35 UTC
[asterisk-users] New CentOS 5 repo: dahdi, asterisk, freepbx RPMs
Dear list,
I've set up an RPM repository with several asterisk-related RPMs that I
think contain some improvements upon what are already out there. The
first goal is to be able to build an Asterisk + FreePBX system on CentOS
5 with the EPEL repo enabled; in our environment, where all our systems
are under configuration management, either an appliance-type solution or
a manual configure/make/make install process is undesirable.
The FreePBX RPM is the biggest improvement; this RPM can be meaningfully
manipulated with rpm -e/-V, installs with all the latest updates, and
has some other basic bits you'd expect (but that no other FreePBX RPM
seems to provide). This is written from scratch.
The DAHDI SRPMs can build kernel module RPMs against any installed
kernel-devel RPM, and also build OSLEC modules. The Asterisk RPM is
provided for completeness, and is lightly customized to work better with
the FreePBX RPM. These RPMs are modified versions of the ATrpms
packages (Thanks, Axel).
I'm quite interested to get feedback on these RPMs, both on the need for
such a repo as well as (if there actually is a need) problems and
improvements that can be made. I'll be monitoring this thread as well
as comments in the blog announcements (links below).
NOTE that these RPMs are not well-tested and upgrades are practically
untested; they should not be depended upon in production environments,
and backups should be made before any upgrades.
Thanks, and looking forward to your comments.
John
The repo information page:
http://www.zultron.com/rpm-repo/
The repo announcement:
http://www.zultron.com/2009/03/the-zultron-el5-rpm-repository/
FreePBX RPM announcement:
http://www.zultron.com/2009/03/freepbx-rpms/
DAHDI RPM announcement:
http://www.zultron.com/2009/03/dahdi-rpms/
Asterisk RPM announcement:
http://www.zultron.com/2009/03/asterisk-rpms/
A FreePBX RPM HOWTO:
http://www.zultron.com/2009/03/freepbx-rpm-on-lighttpd-howto/
Axel Thimm
2009-Mar-25 19:09 UTC
[asterisk-users] New CentOS 5 repo: dahdi, asterisk, freepbx RPMs
Hi John, On Thu, Mar 26, 2009 at 12:35:45AM +0800, John Morris wrote:> I've set up an RPM repository with several asterisk-related RPMs > that I think contain some improvements upon what are already out > there. [...]> I'm quite interested to get feedback on these RPMs, both on the need > for such a repo as well as (if there actually is a need) problems > and improvements that can be made. I'll be monitoring this thread > as well as comments in the blog announcements (links below).How about merging in your changes/improvements/new packages with ATrpms (and automatically later into rpmrepo.org)? That way we won't have further fragmentation and a larger user base to test bits (which will be distributed in stable, testing etc repos). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20090325/bdcbbf99/attachment.pgp
Tzafrir Cohen
2009-Mar-26 16:34 UTC
[asterisk-users] New CentOS 5 repo: dahdi, asterisk, freepbx RPMs
Hi, On Thu, Mar 26, 2009 at 12:35:45AM +0800, John Morris wrote:> Dear list, > > I've set up an RPM repository with several asterisk-related RPMs that I > think contain some improvements upon what are already out there. The > first goal is to be able to build an Asterisk + FreePBX system on CentOS > 5 with the EPEL repo enabled; in our environment, where all our systems > are under configuration management, either an appliance-type solution or > a manual configure/make/make install process is undesirable. > > The FreePBX RPM is the biggest improvement; this RPM can be meaningfully > manipulated with rpm -e/-V, installs with all the latest updates, and > has some other basic bits you'd expect (but that no other FreePBX RPM > seems to provide). This is written from scratch. > > The DAHDI SRPMs can build kernel module RPMs against any installed > kernel-devel RPM, and also build OSLEC modules. The Asterisk RPM is > provided for completeness, and is lightly customized to work better with > the FreePBX RPM. These RPMs are modified versions of the ATrpms > packages (Thanks, Axel).The packages appear (at first glance) to be rather well-built. However they do manifest a common issue: patching cruft. Here is part of dahdi-linux.spec: %patch2 -p1 -b .diet cd ../.. perl -pi -e's,mknod,:,' Makefile grep -rl '#include <linux/config.h>' . | xargs perl -pi -e's,#include <linux/config.h>,/* #include <linux/config.h> */,' perl -pi -e's,^always,#always,' drivers/dahdi/xpp/Kbuild Patch2 is: --- kernel/xpp/xbus-core.c.diet 2007-03-01 20:50:34.000000000 +0100 +++ kernel/xpp/xbus-core.c 2007-04-26 10:55:47.000000000 +0200 @@ -160,7 +161,7 @@ * a bit earlier (2.6.18). If you use such a kernel, Change the * following test from 2,6,19 to 2,6,18. */ -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19) +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18) #define I_PRIVATE(inode) ((inode)->u.generic_ip) #else #define I_PRIVATE(inode) ((inode)->i_private) 1. For some versions of Fedora (and maybe also Centos 5.2?) the respective code has been backported. It is only used in some debugging code. It's all inside '#ifdef XPP_DEBUGFS' . Originally that one was defined if the debugfs was available. Later on it was simply dropped by default. The patch lives on. 2. Next we have patching out of mknod, instead of using 'DYNFS=yes'. 3. Third line patches all the lines with <linux/config.h> in the tree: This seems necessary: $ grep -r linux/config.h drivers/dahdi/ drivers/dahdi/datamods/hdlc_generic.c:#include <linux/config.h> drivers/dahdi/datamods/syncppp.c:#include <linux/config.h> drivers/dahdi/wct4xxp/vpm450m.c:#include <linux/config.h> drivers/dahdi/dahdi_config.h:#include <linux/config.h> But let's look again: $ grep -r -C 1 linux/config.h drivers/dahdi/ drivers/dahdi/datamods/hdlc_generic.c- drivers/dahdi/datamods/hdlc_generic.c:#include <linux/config.h> drivers/dahdi/datamods/hdlc_generic.c-#include <linux/module.h> -- drivers/dahdi/datamods/syncppp.c- drivers/dahdi/datamods/syncppp.c:#include <linux/config.h> drivers/dahdi/datamods/syncppp.c-#include <linux/module.h> -- drivers/dahdi/wct4xxp/vpm450m.c-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18) drivers/dahdi/wct4xxp/vpm450m.c:#include <linux/config.h> drivers/dahdi/wct4xxp/vpm450m.c-#else -- drivers/dahdi/dahdi_config.h-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18) drivers/dahdi/dahdi_config.h:#include <linux/config.h> drivers/dahdi/dahdi_config.h-#else The PPP stuff has not been patched (anybody uses it?). The kernel stuff has been fixed. 4. Next we have a patch that disables a build-time test in the xpp directory. That test has failed at some point. This was indeed one of the cases where a test failed but won't fail at run-time. However, this was fixed at 2.1.0.3: http://bugs.digium.com/view.php?id=13832 Do I expect you all packagers to know the internals of a package? To know that some code is now no longer built at all? Surely no. This is why you should report such issues upstream. As a rule: every patch that you have is a potential bug. It should carry an explanation. One good explanation is a reference to a bug tracker issue. If a bug is not reported upstream, how will it be solved? The DYNFS thing is still something I'm not happy with. I think that almost all users of DAHDI now use udev. Hence using anything else should be the exception. Not to mention udev works well out of the box: with most systems device files will now be generated correctly even without udev rules, and the udev rules are only needed to set permissions. I'd like to see this default changed on the next version of DAHDI. But having packages just patch the problem away and not even monitor an open bug about it, means they'll miss this change. Another bad form of laziness is patching with perl scripts instead of proper patches. A perl script is less likely to break. But this is the reason why you should (actively) have to maintain a patch: if something has changed around the patched area, maybe you need to reconsider the patch. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir