[asterisk-users] New CentOS 5 repo: dahdi, asterisk, freepbx RPMs

[Tzafrir Cohen]

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