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

[Dan S]

2012/8/13 Felipe Sateler <fsateler at debian.org>:
> 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.

As discussed, 3.4 is not a fantastic package, but it does provide the
core language+server, so option 1 seems pointless when bug #674386
apparently has a fix we can go straight for. I don't have any strong
motivation to go into negotiations with the RT for option 2: although
3.4 is less than ideal, once it's shipped we can focus on making the
3.5 sid package great. So I suggest let's go for TPU.

Dan