Bug#713670: supercollider: FTBFS: sndfile_backend_test.cpp:46:34: error: expected unqualified-id before numeric constant

[Felipe Sateler]

On Sun, Jun 23, 2013 at 3:27 PM, Dan S <danstowell+debmm at gmail.com> wrote:
> 2013/6/23 Felipe Sateler <fsateler at debian.org>:
>> On Sat, Jun 22, 2013 at 2:23 PM, Dan S <danstowell+debmm at gmail.com> wrote:
>>> Hi -
>>>
>>> Thanks for the report. The "testsuite" does not need to be built for
>>> packaging, so actually we disable it in the most recent version in
>>> debian-git and in experimental (which is supercollider 3.6.3). We can
>>> do this for 3.5.3 as well, which will fix this issue.*
>>
>> Why disable the testsuite? After all, if it is failing, its for a reason....
>
> That's what I thought too at first. However it's not intended to be
> packaged (it doesn't build anything), and after discussion with the
> developer who actually made and maintains that testsuite, he wanted it
> that way... (It's not really a testsuite of supercollider, btw, I
> think covers the 'supernova' component.)
>
>>> However, I'm not sure what the best way is to go about implementing
>>> this fix. In the debian-git we've already moved forward to
>>> supercollider 3.6.3. So, should I apply the fix I give below on a new
>>> git branch from debian/1%3.5.3_repack-3, and then request upload to
>>> sid (and jessie?)? Or, should we instead look at migrating 3.6.3 from
>>> experimental to sid?
>>
>> Lets not waste time fixing old versions.
>
> OK
>
>> I'm sorry for delaying the
>> 3.6 uploads, but I've been busy, and I'm kind of uncomfortable with
>> the current state because sc requires a newer boost version than the
>> debian default, which would require hardcoding a given boost version
>> in the build-deps.
>
> OK so at present the boost dependencies are of this form:
>  "libboost-dev (>= 1.50) | libboost1.50-dev"
>
> In sid/jessie/experimental there is a set of boost packages which
> should work, but named in the form "libboost1.53-dev". It would be OK
> to add these as allowable alternatives, I think? I see no harm; it's
> not the debian default but it's in debian. Unless there's something
> going on which would mean we have to remove the more generic
> dependency in order to have this one used, which would be a bit of a
> shame (though still maintainable).

Unfortunately, the buildds only take into account the first
alternative dependency, so it should be libboost1.5x-dev |
libboost-dev (>= 1.50).

>
> (I don't actually understand why pages such as
> <http://packages.debian.org/experimental/supercollider-language> state
> the dependency as eg "libboost-filesystem1.50.0 (>= 1.50.0-1) [Package
> not available]". If the dependency is perhaps being inferred from the
> build phase, why would an unavailable libraryversion be present at
> build time?)

I suppose the reason is that it was available when it was built ;).
Looks like the archive software doesn't look in experimental to see if
the libs are still used before dropping them. This should not happen
(I think) if sc is uploaded to unstable.

--

Saludos,
Felipe Sateler