Bug#674386: supercollider: FTBFS: scons: *** No SConstruct file found.

Felipe Sateler fsateler at debian.org
Mon Aug 13 14:51:03 UTC 2012


On Sun, Aug 12, 2012 at 5:37 PM, Dan S <danstowell+debmm at gmail.com> wrote:
> 2012/8/12 peter green <plugwash at p10link.net>:
>>>
>>> I'd like to mark this as "won't fix" because we're dropping the scons
>>> build system. The latest version of supercollider 3.5.x (which I'm
>>> currently asking debian-multimedia maintainers to upload) uses cmake
>>> instead which is much less mess.
>>>
>>
>> Supercollider 1:3.5.2-1 was uploaded just before the freeze deadline,
>> however
>> it did not migrate to testing due to build failures.
>>
>> So if supercollider is going to release with wheezy you either need to open
>> discussions with the release team about either getting a freeze exception
>> for
>> the version in sid or making a TPU upload to fix the scons build system in
>> the wheezy package
>
> Thanks. I'm not very familiar with debian processes so I'd appreciate
> guidance from pkg-multimedia-maintainers on this. I don't know how to
> do either of the things you describe, or which is better. (What's
> TPU?) In git I made a branch "3.4debianfixes" which potentially
> contains a fix for the scons issue.

The basic process is described by Raphael Hertzhog at [1]. The
description, however, does not describe the current issue. What
happens if testing is frozen, there is a bug in the package in
testing, and there is a newer release in unstable? There are three
options:

1. Remove the software from testing (and therefore, from the next
stable release).
2. Somehow convince the release team that the new version in unstable
should migrate to testing.
3. Upload a localized fix to testing-proposed-updates (TPU for short,
a special "distribution" meant for fixes that cannot go through
unstable).


Each option has its benefits and drawbacks. The release team usually
prefers option 3. Rewriting the choices for our current situation, we
have:

1. Do not release supercollider in wheezy
2. Somehow convince the rt that 3.5 should migrate.
3. Ship 3.4 with the fix, via an upload to tpu.


As I see it, there are significant drawbacks with the standard option
(n° 3), because I'm not quite sure if 3.4 offers the best experience
for users. However, I'd prefer if you (Dan) made this call, because
you know sc much better, and thus can make a more informed decision.
At this point, option 2 looks very unlikely, though. We can try to do
it, but it is more likely that we will end up doing either 1 or 3. But
we need to be clear on which one to do.


[1] http://raphaelhertzog.com/2010/10/18/understanding-debians-release-process/

-- 

Saludos,
Felipe Sateler



More information about the pkg-multimedia-maintainers mailing list