uw-imap and asterisk

[Kilian Krause]

Hi Faidon, Jonas,

On Mon, Aug 27, 2007 at 03:58:15PM +0300, Faidon Liambotis wrote:
> Jonas Smedegaard wrote:
> > I am aware of this. And have struggled to make a local sideport of
> > Asterisk actually compile against a recent uw-imap. Without luck.
> Well, it *works* with current trunk. It needed a tiny change in
> configure (-lc-client instead of /usr/include/c-client/c-client.a) and
> just worked :-)
> 
> > UW-imap upstream has a weird way of compiling. But for Debian I have
> > considered introducing a pkg-config file, to ease autotools-based use of
> > libc-client for things like asterisk.
> > 
> > Would you be interested in that? Perhaps help make the needed
> > adjustments? Or do you perhaps find it a wrong thing to do?
> To be honest, I'm not really interested since compilation currently
> works for me.
> 
> > I maintain 40+ packages officially for Debian, and have found packaging
> > routines that I would not like to change too much in odd directions -
> > instead I want to streamline the packaging across the packages even more.
> > 
> > UW-imap is packaged using CDBS, and that won't change. Also, patches are
> > done using quilt - I find dpatch disgusting to work with.
> You misunderstood. I don't propose to comaintain the package (it is out
> of pkg-voip's scope) and personally I don't really care how is it
> packaged, as long as it has a maintainer.
> [however, I agree completely about quilt and that's why asterisk
> switched to quilt]

just for the record, the snapshotting can do with both CDBS and quilt
perfectly fine. There's a number of packs to proove it already. ;)


> > From a quick look at those snippets in the asterisk package, they seem
> > to not be needed with my current CDBS-based packaging mechanisms - if
> > you are willing to add a "flag" to the autobuilders doing side- and
> > backports: If you include cdbs-autoupdate to DEB_BUILD_OPTS then
> > build-dependencies are recalculated at build time, and for the cases
> > where that by itself does not automagically solve issues, it is easy to
> > include needed adjustments as ifdef's within debian/rules.
> I'm not sure about the backporting procedure; Kilian can help with that.
> I'm under the impression that it only executes debian/backports/$DIST
> scripts.
> Have in mind that SRTP, which you maintain, is being snapshotted; you
> don't have to do anything different than what you are doing there.

The backports works as follows:
a) if there is no script, just ship the source "as is" to each dist
b) if there is a script with the name of the dist, run it, then wrap up
   the source and put it into the archive

This makes it perfectly possible to have sources that just go without
any backport hook scripts into all dists while others need about one per
each dist supported.

The fact that SRTP is broken on sparc would even have shown in
Buildserver.NET if the sparc buildd wouldn't currently have an issue
with dpkg-query (that's the fact it's only building sarge and dapper for
now).


> Anyway, this is not such a big deal since there is no need yet.
> The more important question remains however: do you maintain in a VCS
> that the buildserver can have access to?
> AFAIK, buildserver can't snapshot unstable, only version control systems.

For now, yes. It may be possible to overly complicate things in the
script and read back Sources files from your next mirror, but if there's
no large demand it's unlikely this gets fixed/added.


> > Looking forward to asterisk with imap support!
> That's already being done in our SVN and will be in the next upload to
> Debian. This is going to take a while though, since we want to have the
> current version in testing first.
> 
> It's backports that is the problem, currently.

To be a bit more precise: it's the fact we want asterisk backported that
we now require backports of uw-imap. For this, we'd welcome to have a
public VCS to make source snapshots from.
To ease the testing of new upstream releases it'd be highly welcomed if
you could add a get-orig-source target to debian/rules. Then the script
needn't wait for the Debian mirrors to have a fresh copy of the
orig.tar.gz.

As always, if there's any more demand to clarify things about
Buildserver.NET, please do not hesitate to ask. ;)

-- 
Best regards,
Kilian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20070827/95d768f0/attachment.pgp