Hello,
This is a update on the current status of Asterisk in Debian.
Apologies for the really long mail, it is targetted both to users and
maintainers :)

I'm Ccing asterisk-users as a one-time thing; users that are interested
can subscribe to our list[1] for updates to prevent noise on a
non-Debian list. Please Cc pkg-voip-maintainer on replies.

1: http://lists.alioth.debian.org/mailman/listinfo/pkg-voip-maintainers

sarge/etch status
-----------------
About a month ago, I fixed all the long-standing knownn vulnerabilities
in both sarge/oldstable (1.0.7) and etch/stable (1.2.12).
The updates are present security.debian.org a Advisory has been released
(DSA-1358[1]), thanks to Debian's Security Team.

These updates are fixing CVE-2007-1306, CVE-2007-1561, CVE-2007-2294,
CVE-2007-2297, CVE-2007-2488, CVE-2007-3762, CVE-2007-3763 and
CVE-2007-3764 (...).

1: http://www.debian.org/security/2007/dsa-1358

lenny status
------------
1:1.4.11~dfsg-4 has been recently uploaded to unstable.
The previously mentioned block by the openh323 dependency which
currently fails to build in unstable (binutils bug: #440015) has been
workaround-ed (by having less strict shlibs in openh323)

>From our POV, it's a good candidate for lenny/testing. However:
 - it depends on perl and net-snmp versions that are not present in
   testing and are not in a shape to be there; we'll need new versions
   from the respective teams.
 - asterisk needs to go together with yate because of a shared libpri
   dependency. However yate is being blocked[2] by gtk+2.0.
 - more importantly, asterisk produces an Internal Compiler Error of GCC
   4.2 on hppa (#445336). Until it builds successfully there, it cannot
   migrate to testing.

1: http://bjorn.haxx.se/debian/testing.pl?package=asterisk
2: http://bjorn.haxx.se/debian/testing.pl?package=yate

1.4.12
------
Digium released 1.4.12 the day before yesterday. I have committed all
the changes needed and we are now up to date.
Fortunately, many of our fixes that I reported upstream have been
merged. I have manually ported bristuff 0.4.0-test4 to 1.4.12; it needed
many changes compared to the previous upstream updates.
I will forward my changes to kapejod so that he can hopefully release a
new version.

supplementary packages
----------------------
* asterisk-addons (-mp3, -mysql, -ooh323c) are finally present in Debian
  and should be ready to migrate to lenny after Asterisk does. Digium
  released a new version along with 1.4.12 and I will update this ASAP.
* asterisk-chan-capi, asterisk-spandsp-plugins, asterisk-oh323 had
  recents uploads and all are in a good shape.
* I am going to drop rate-engine from the archive (#444712) since it has
  no users, it wasn't released with etch, has open bugs for a really
  long time and is unmaintained by upstream.
* I tried compiling chan_misdn together with the mISDN maintainer (Simon
  Richter) and failed because of an mISDN API mismatch.
  Need to take another look.
* asterisk-gui needs to be uploaded; Tzafrir?
* are we going to upload ARI? If not, we should drop it from our SVN.
* zaptel is in a good status and it's the only package from the suite
  that is migrating to testing. Things TODO that come to mind are: a)
  fixing a bug which results in /lib/modules/2.6.foo/modules.* files in
  amd64 and b) evaluate a switch to OSLEC as the default echo
  cancellator. Tzafrir is doing an excellent job on maintaining this
  package by himself :)
* Right now, we are shipping asterisk-sounds-main which is the "main"
  asterisk sounds in English in GSM format -- exactly as shipped in the
  original tarball by Digium. Kilian, Tzafrir and me were pondering on
  the idea of shipping separately all sounds as shipped by Digium in all
  formats (besides WAV), each in a separate package. This should serve
  our users better but has an obvious problem of size. This is not
  decided yet.

ABI issues
----------
Most -if not all- of these plugins build-depend on asterisk-dev i.e. use
Asterisk's development headers. These headers are tied to the ABI and
this can only be expressed in dependencies manually.
asterisk-chan-capi was compiled with 1.2 asterisk-dev, had a >= 1.2
dependency but segfaults on 1.4 (#441237). There are currently no
similar problems that I know of.
However, we should expect more of these when we transition to 1.6 which
will most probably have a different ABI.

I'm leaning towards a solution:
 * Add a "Provides: asterisk-1.4" to asterisk.
 * Replace "Depends: asterisk (>= 1.4.0)" (or similar) with "Depends:
   asterisk-1.4" on all external modules.
This should help in *breaking*, dpkg-wise, the modules when a new
version is uploaded which in turn will prevent a new version from
entering testing until all plugins are recompiled.

pushing our work upstream
-------------------------
On the 1.4.11-1.4.12 cycle, I tried pushing all of our patches to
Digium's BTS (mantis). This has worked well since they're quite
responsive (contrary to our secondary upstream, Klaus-Peter Junghanns...).
I have began adding comments to all of our patches with either:
 * the Digium ticket number
 * a temporary "should be forwarded upstream" tag
 * what's wrong with a patch that makes it unsuitable for forwarding it
I find this a good "policy" that we should probably adopt for all
pkg-voip's packages.

getting upstream's work back :)
-------------------------------
Digium is following an old-style Linux release model (odd-even
versions). Unfortunately, this leads to long delays between interesting
features or non-trivial fixes.
This, combined with our long release cycles can result in *huge* delays.
For example, we shipped etch in April with Asterisk 1.2 and Asterisk 1.4
was feature-frozen for already 3 months at that point.

We are currently shipping func_devstate (it is maintained for 1.4
out-of-tree by its author, Russell Bryant) and I have just commited a
backport of the libcap patch so that asterisk can set the ToS of IP.

I have also backported chan_mobile for asterisk-addons; I'm going to buy
a Bluetooth adapter and test it before uploading, however.

Backporting stuff from trunk may be error-prone and is not easy to draw
a line of which stuff we should backport.
I'm open to suggestions on other modules that may have sense in backporting.

bugs
----
Our bug count is currently:
* Status
    - 8 Outstanding
    - 3 Forwarded
* Severity
    - 2 Important bugs
    - 2 Normal bugs
    - 7 Wishlist items
This is probably the lowest bug count in ages, partly because testing
has still 1.2.

I have begun forwarding upstream bugs to mantis. This has already been
proven fruitful: #353227 is open for 1 year and 230 days; I forwarded it
on 2007-09-21 and got a proposed patch back on the very next day!

I'm expecting more bugs when asterisk migrates in testing; we can only
cope up with them if we tag them properly and forward the upstream ones
quickly.

helping out
-----------
You can help by testing our packages and reporting bugs if found.
Besides frequent uploads to unstable, there is buildserver that has
revision snapshots for etch, lenny, sid[1] and edgy, feisty and gutsy[2]

Any feedback is welcome; suggestions on how to improve the packaging,
bug reports, backport requests, suggested out-of-tree patches for
inclusion etc.

1: http://pkg-voip.buildserver.net/debian/
2: http://pkg-voip.buildserver.net/ubuntu/
(apt repositories)

Best regards,
Faidon

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to