getting the asterisk module loadable

[Geert Stappers]

On Sat, Oct 13, 2012 at 09:02:56PM +0200, Jonas Smedegaard wrote:
> On 12-10-13 at 04:08pm, Geert Stappers wrote:
> > Here a message from the Utrecht BSP 2012.
> > ( http://wiki.debian.org/BSP/2012/10/nl/Utrecht )
> > 
> > Bugreport 685540 is release critical according
> >  http://bugs.debian.org/release-critical/other/testing.html
> > so I spend some time on it and go it fixed.
> > 
> > When compiling with asterisk installed, I get a loadable app_flite.so
> > 
> > In other words: A build-depend on asterisk solves this issue.
> 
> I believe your reasoning is flawed: Compiling _without_ adding a 
> build-dependency on asterisk _also_ makes app_flite.so loadable.

That does makes sense, at least it matches my observation:
 "module was loadable after a recompile"


> > I gonna do a non-maintainer upload to the 10 days delay queue.
> 
> Thanks for the attempt - but please cancel that misleading upload unless 
> you can provide additional info contraditing what I wrote above.

There was a `dput --delayed 10` down and after that a `dcut`.
In ten day we know for sure that cancel was succesfull.
If my `dcut` was unsuccesfull, we get a "binNMU"  :-/


> The specific issue needs only a simple binNMU,

That information is now in this bugreport.

> which the release team has judged is wrong to do.

Having the reason in this BR would be nice.


> The underlying issue is that asterisk fails to provide proper shlibs 
> hinting, so that packages building against asterisk do not get versioned 
> binary dependencies that can reveal leed for binNMU later on.  That 
? binary dependencies that can reveal need for binNMU later on.  That 
> underlying issue needs to be reported against asterisk and fixed there.

The Debian maintainers of asterisk are in the Cc.

Reporting the issue in a BR is now, wheezy release freeze, not done.


Groeten
Geert Stappers
-- 
> And is there a policy on top-posting vs. bottom-posting?
Yes.