Bug#674386: supercollider: FTBFS: scons: *** No SConstruct file found.
On Sun, Aug 12, 2012 at 5:37 PM, Dan S danstowell+de...@gmail.com wrote: 2012/8/12 peter green plugw...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674386: supercollider: FTBFS: scons: *** No SConstruct file found.
2012/8/13 Felipe Sateler fsate...@debian.org: On Sun, Aug 12, 2012 at 5:37 PM, Dan S danstowell+de...@gmail.com wrote: 2012/8/12 peter green plugw...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674386: supercollider: FTBFS: scons: *** No SConstruct file found.
2012/8/12 peter green plugw...@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. Dan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674386: supercollider: FTBFS: scons: *** No SConstruct file found.
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674386: supercollider: FTBFS: scons: *** No SConstruct file found.
Hi - Thanks for reporting this. The problem seems to be something to do with dh's automatic invocation of scons to perform cleaning - if you look at the log you'll see that the package successfully builds (calling scons on the directory ./common), but the clean step invokes scons on the . directory which is incorrect. 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. Best Dan 2012/5/24 Lucas Nussbaum lu...@lucas-nussbaum.net: Source: supercollider Version: 1:3.4.5-1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20120524 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: debian/rules build test -x debian/rules mkdir -p common WARNING: copyright-check disabled - licensecheck (from devscripts package) is missing. touch debian/stamp-copyright-check touch debian/stamp-upstream-cruft scons --directory=. CC=cc CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall CXX=g++ CXXFLAGS= DEVELOPMENT=yes PREFIX=/usr CROSSCOMPILE=1 CURL=0 SCVIM=0 SCED=0 STRIP=0 scons: *** No SConstruct file found. File /usr/lib/scons/SCons/Script/Main.py, line 904, in _main make: *** [debian/stamp-scons-build] Error 2 The full build log is available from: http://people.debian.org/~lucas/logs/2012/05/24/supercollider_3.4.5-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot. Internet was not accessible from the build systems. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674386: supercollider: FTBFS: scons: *** No SConstruct file found.
Source: supercollider Version: 1:3.4.5-1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20120524 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: debian/rules build test -x debian/rules mkdir -p common WARNING: copyright-check disabled - licensecheck (from devscripts package) is missing. touch debian/stamp-copyright-check touch debian/stamp-upstream-cruft scons --directory=. CC=cc CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall CXX=g++ CXXFLAGS= DEVELOPMENT=yes PREFIX=/usr CROSSCOMPILE=1 CURL=0 SCVIM=0 SCED=0 STRIP=0 scons: *** No SConstruct file found. File /usr/lib/scons/SCons/Script/Main.py, line 904, in _main make: *** [debian/stamp-scons-build] Error 2 The full build log is available from: http://people.debian.org/~lucas/logs/2012/05/24/supercollider_3.4.5-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot. Internet was not accessible from the build systems. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
