Re: FTBS of ardour

["Felipe Sateler" <fsateler@gmail.com>]

On 10/23/07, Nico Golde <nion@debian.org> wrote:
> Hi Felipe,
> * Felipe Sateler <fsateler@gmail.com> [2007-10-23 10:22]:
> > On Sunday 21 October 2007 08:19:23 Nico Golde wrote:
> > > Hi Ardour maintainers,
> > > Did someone of you already look into:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446597?
> > > I ask because this is the only thing missing from fixing the
> > > security flaw in ardour described on:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445889
> >
> > I've been looking into this. The pkg-config issue is trivial, a pkg-config
> > build-dep was missing.
>
> Are you sure about this? I don't really think so I think
> this is a scons issue, if you look at the build log failing
> because of pkg-config you can see another place where
> pkg-config is there in the same build

Ah, this is true. I failed to see that pkg-config was brought in by
some dependency earlier, and that the failure was when cleaning. I
know what the problem is, but unfortunately there is nothing we can
do, please see scons bug 444204. In short, the problem is that the
current snapshot in unstable doesn't actually execute configuration
directives when called with -c (clean) or -h (help). This has the side
effect that all configure calls return false, which makes cleaning and
asking for help break. This is apparently fixed in upstream svn, but
hasn't got here yet.
I wasn't able to reproduce the problem here since I have scons on hold
for exactly this reason (I do feel somewhat embarrased for not seeing
this before, though).

>
> > I'm having a problem with the abs issue, though: I
> > can't understand why it is there, and it doesn't appear here on i386.
>
> From what I see the problem is that it does not know to
> which type the value should be converted, there is no
> variant for nframes64_t or int64_t and int64_t is assignment
> compatible with float and int for example.
> So typecasting should solve this.

The strange thing is that this should happen in other 32-bit
architectures too, since the int64_t is defined as a long long int,
which has no abs implementation in the std:: namespace. Anyways, my
patch moved the casting from double to int64_t to after the abs is
done, which should resolve the ambiguity (double std::abs(double) is
present in the C++ standard).

-- 

	Felipe Sateler