2013/6/23 Felipe Sateler <fsate...@debian.org>: > On Sat, Jun 22, 2013 at 2:23 PM, Dan S <danstowell+de...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
