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

[Dan S]

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).

(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?)

Dan