Moving packages to Sid

[Kilian Krause]

--=-hGHJXPLPx6ATHSzy878S
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi Jose,

Am Sonntag, den 20.02.2005, 21:31 +0100 schrieb Jose Carlos Garcia Sogo:
>  Hi,
>=20
>  I think it is time to move stuff to Sid from experimental. There are
> though two things that don't make this 100% clear:
>=20
>    1. asterisk-oh323 is still blocked in NEW queue. Anyway, we are going
> to make asterisk-h323 a fake package, disabling the code. Shipping
> broken binaries is the same than not having them

Agreed. Perfect solution. At least until we can backport chan_h323 from
Asterisk CVS. Even then we should verify its readyness for deployment,
but that's both out of the picture for now.

>    2. zaptel maintainer has not yet replied about some issues for zaptel
> in asterisk. That would be nice to be solved too.

The problem isn't in zaptel, it's in zaphfc. That's a patch that's
needed for BRI-cards (from junghanns.net) and HFC-chip based ISDN-cards
(like i have, for those are *CHEAP* and thus very commonly installed). I
would love to see this patch being applied to zaptel and libpri. For
libpri i do understand that Mark is still busy to catch up and i'd be
willing to risk him blaming me, but as commented earlier, I'd just move
libpri into pkg-voip for now. From the zaptel maintainer I have not yet
received *ANY* feedback other than my bugreport on 1.0.4 being available
being silently fixed (with no Closes against my bug even). Thus I
somewhat feel this maintainer is currently overloaded with other
objections too and if we do want to resolve this long standing issue,
then we'd need to also silently integrate the package into pkg-voip
until he speaks up for further cooperation.=20
This zaphfc patch is *WIDELY* used, it's nothing beta or hackish
quality. It's something that's *NEEDED* to get all of the BRI and HFC
cards to work. If anybody still has any objections why this shouldn't go
in, please speak up now!

>  So, basically, the plan is as follows:
>=20
>   1. Compile pwlib/openh323 mimas release. It will have the same
> "soname" that current packages. We expect that there is no API/ABI
> breakage, but we are not 100% sure. Anyway, changing the name will mean
> that packages are going to get stuck in NEW.

Well, I don't feel very easy with shipping unchecked, but I guess that's
ok and better than going through NEW. We do already have spandsp,
rxfax/txfax, yate and asterisk-oh323 in there. No need to add even more
packs to the ~400 sources in NEW.

>   2. Compile any pacakage depending on them, including asterisk with a
> disabled asterisk-h323 package. For now we are going to keep
> optimization for this package set to i586 till we consider how this
> could be resolved in a way that doesn't mean we ship a unusable package.
> Also, dependencies/recommendations on asterisk-oh323 would be activated
> only when it gets out of NEW.

ok, going for 586 is probably a good idea. The feedback from aefirion
upstream was that only speex and ilbc will suffer from 386 changes. As
we *should* not rely on Debian's speex (very probably that 586
compilation is even related to the broken codec issue), for it does not
work (sic!), anybody who can propose a clean patch for exporting speex
and ilbc libs from the asterisk source is welcome to bring it forth.

>   3. UPLOAD, UPLOAD, UPLOAD

Yes.Yes.YES! ;)

--=20
Best regards,
 Kilian

--=-hGHJXPLPx6ATHSzy878S
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCGP0Avdkzt4X+wX8RAlByAJ9U+anJMWktyk22RvB2U1jX1uQnpACfaOq5
N/1Z8L1WtRXKxs4RuN10f7I=
=/nHB
-----END PGP SIGNATURE-----

--=-hGHJXPLPx6ATHSzy878S--