Bug#766630: supercollider: ftbfs on ppc64el -- error: invalid parameter combination for AltiVec intrinsic

[Dan S]

Hi all -

Felipe has covered most of the reviewing already. Just noting here
that I have proposed to send the nova-simd part of this patch
upstream: , plus:

2014-10-24 16:55 GMT+01:00 Felipe Sateler :
> On Fri, Oct 24, 2014 at 12:27 PM, Konstantinos Margaritis
>>> Perhaps a more correct patch would alter the logic in
>>> server/supernova/CMakeLists.txt to allow passing the
>>> required flags just to supernova
>>
>> That alone won't do for the reasons above.
>
> Hmm, it seems I was unclear. With this comment I was referring to
> adding -maltivec and -mabi=altivec wholesale to supercollider (in
> d/rules), not the vector attribute replacing code.

I am thinking the same as Felipe here.

Best
Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#728573: supercollider: FTBFS on sparc and ppc but built there in the past

[Dan S]

2013/11/6 Felipe Sateler :
> On Sun, Nov 3, 2013 at 7:44 AM, Dan S  wrote:
>>
>> Thanks. As discussed previously on pkg-multimedia-maintainers, I
>> propose that we restrict archs for one package
>> "supercollider-supernova". The package is optional for users (it's a
>> non-default drop-in alternative to "supercollider-server") and there
>> is very little upstream support for getting it working across archs.
>> It uses some fancy coding and boost libs that I'm not familiar with,
>> and these are what incur these build fails. I know it would be great
>> to avoid having to special-case any archs, but I don't see where the
>> expertise will come from to do this, and supercollider is
>> fully-functional without that package.
>
> I thought sc used the problematic boost libs elsewhere so this was not
> really a workable solution...

Hi all - just tested this on sparc/ppc porterboxes and the proposed
fix works. I've pushed the fix to git.debian.org - please could I
request a new upload, so that it's possible for the supercollider
packages to go eventually to testing?

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#728952: supercollider-emacs: sc-emacs fails to install with xemacs installed

[Dan S]

Hi IOhannes,

I'm perhaps the main debian SC maintainer, and unfortunately I am not
an emacs user. The supercollider-emacs package is specified to depend
simply on "emacs23 | emacsen" which looks innocent enough to me. If
"the site-lisp for xemacs" is incompatible with "xemacs" then surely
it's an issue for xemacs maintainers? Or if there is a fix/workaround
that you can recommend, please recommend.

Dan


2013/11/7 IOhannes m zmoelnig :
> Package: supercollider-emacs
> Version: 1:3.6.3~repack-3
> Severity: normal
>
> installing supercollider-emacs with xemacs21 installed, will try also install
> the site-lisp for for xemacs.
> unfortunately these are incompatible with xemacs, making the package
> uninstallable.
>
> attached is the output of `apt-get -f install`
>
> fgamsdr
> IOhanens
>
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
> 'experimental')
> Architecture: i386 (i686)
>
> Kernel: Linux 3.10-3-686-pae (SMP w/4 CPU cores)
> Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages supercollider-emacs depends on:
> ii  emacs23 [emacsen]23.4+1-4.1
> ii  supercollider-language   1:3.6.3~repack-3
> ii  xemacs21-mule [emacsen]  21.4.22-4
>
> Versions of packages supercollider-emacs recommends:
> ii  w3m-el  1.4.483+0.20120614-3
>
> supercollider-emacs suggests no packages.
>
> -- no debconf information
>
> ___
> 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#728573: supercollider: FTBFS on sparc and ppc but built there in the past

[Dan S]

Thanks. As discussed previously on pkg-multimedia-maintainers, I
propose that we restrict archs for one package
"supercollider-supernova". The package is optional for users (it's a
non-default drop-in alternative to "supercollider-server") and there
is very little upstream support for getting it working across archs.
It uses some fancy coding and boost libs that I'm not familiar with,
and these are what incur these build fails. I know it would be great
to avoid having to special-case any archs, but I don't see where the
expertise will come from to do this, and supercollider is
fully-functional without that package.

Dan


2013/11/3 Niels Thykier :
> Package: supercollider
> Version: 1:3.6.3~repack-3
> Severity: serious
>
> Hi,
>
> supercollider FTBFS on the sparc and powerpc buildds, but was built
> there successfully in the past.  Since sparc and powerpc are
> candidates for release architectures, this failure prevents testing
> migration.
>
> ~Niels
>
> Ref: https://buildd.debian.org/status/package.php?p=supercollider
>
> ___
> 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#722430: supercollider: Should use system yaml-cpp

[Dan S]

2013/9/13 Felipe Sateler :
> On Fri, Sep 13, 2013 at 4:26 AM, Dan S  wrote:
>> Ah, that's useful. Actually, though, I don't believe porting is
>> required. The yaml-cpp website says that the old 0.3 API "will
>> continue to be supported, and will still receive bugfixes", and debian
>> has libyaml-cpp0.3 available everywhere.
>
> In debian, the 0.3 package is built from the same sources, so it is
> bound to go away at some point. The headers also do not match the 0.3
> version. I tried building using system yaml-cpp but it failed.

Using system yaml-cpp 0.3, as implemented in my commit? Curious -
worked for me. I don't see why 0.3 is bound to go away in the
medium-term, given that their upstream is so loud about keeping it.
But I don't mind either way - if you think, then we should reverse my
commit.

Dan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#722430: supercollider: Should use system yaml-cpp

[Dan S]

Ah, that's useful. Actually, though, I don't believe porting is
required. The yaml-cpp website says that the old 0.3 API "will
continue to be supported, and will still receive bugfixes", and debian
has libyaml-cpp0.3 available everywhere.

Fixed in 5f4d0fb

Thanks
Dan



2013/9/10 Felipe Sateler :
> Source: supercollider
> Version: 1:3.6.3~repack-2
> Severity: normal
>
> Debian now has yaml-cpp, so supercollider should use it. Unfortunately,
> sc requires yaml 0.3, so some porting seems to be required.
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (101, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> -- no debconf information
>
> ___
> 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#713670: supercollider: FTBFS: sndfile_backend_test.cpp:46:34: error: expected unqualified-id before numeric constant

[Dan S]

2013/6/23 Felipe Sateler :
> On Sat, Jun 22, 2013 at 2:23 PM, Dan S  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

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

[Dan S]

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

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?

Best
Dan


*
diff --git a/debian/rules b/debian/rules
index 13c50e1..8d69335 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,7 +20,7 @@ DEB_INSTALL_MANPAGES_supercollider-supernova =
debian/supernova.1
 DEB_INSTALL_MANPAGES_supercollider = debian/sclang.1
 DEB_INSTALL_MANPAGES_supercollider-vim = debian/scvim.1
debian/sclangpipe_app.1

-DEB_CMAKE_EXTRA_FLAGS = -DDSO_VISIBILITY=on -DSUPERNOVA=on
-DSC_EL_BYTECOMPILE=OFF
+DEB_CMAKE_EXTRA_FLAGS = -DDSO_VISIBILITY=on -DSUPERNOVA=on
-DSC_EL_BYTECOMPILE=OFF -DENABLE_TESTSUITE=off

 # Exclude external libs from the source package if unused on linux or
using system-supplied
 DEB_UPSTREAM_REPACKAGE_EXCLUDES = \



2013/6/22 David Suárez :
> Source: supercollider
> Version: 1:3.5.3~repack-3
> Severity: serious
> Tags: jessie sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20130620 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part:
>> make[3]: Entering directory `/«PKGBUILDDIR»/obj-x86_64-linux-gnu'
>> /usr/bin/cmake -E cmake_progress_report 
>> "/«PKGBUILDDIR»/obj-x86_64-linux-gnu/CMakeFiles"
>> [100%] Building CXX object 
>> testsuite/supernova/CMakeFiles/sndfile_backend_test.dir/sndfile_backend_test.cpp.o
>> cd "/«PKGBUILDDIR»/obj-x86_64-linux-gnu/testsuite/supernova" && /usr/bin/g++ 
>>   -DSC_DATA_DIR=\"/usr/share/SuperCollider\" -DSC_LINUX -g -O2 
>> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
>> -Wall -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG -I"/«PKGBUILDDIR»/include/common" 
>> -I"/«PKGBUILDDIR»/include/plugin_interface" 
>> -I"/«PKGBUILDDIR»/include/server" -I"/«PKGBUILDDIR»/server/supernova" 
>> -I"/«PKGBUILDDIR»/external_libraries/boost" 
>> -I"/«PKGBUILDDIR»/external_libraries/boost_endian" 
>> -I"/«PKGBUILDDIR»/external_libraries/boost_lockfree" 
>> -I"/«PKGBUILDDIR»/external_libraries/boost_move" 
>> -I"/«PKGBUILDDIR»/external_libraries/oscpack" 
>> -I"/«PKGBUILDDIR»/external_libraries" 
>> -I"/«PKGBUILDDIR»/external_libraries/nova-tt" 
>> -I"/«PKGBUILDDIR»/external_libraries/TLSF-2.4.6/src"-fschedule-insns2 
>> -fomit-frame-pointer -Wreturn-type -fvisibility=hidden -pthread -o 
>> CMakeFiles/sndfile_backend_test.dir/sndfile_backend_test.cpp.o -c 
>> "/«PKGBUILDDIR»/testsuite/supernova/sndfile_backend_test.cpp"
>> In file included from /usr/include/pthread.h:24:0,
>>  from 
>> /usr/include/x86_64-linux-gnu/c++/4.8/bits/gthr-default.h:35,
>>  from /usr/include/x86_64-linux-gnu/c++/4.8/bits/gthr.h:148,
>>  from /usr/include/c++/4.8/ext/atomicity.h:33,
>>  from /usr/include/c++/4.8/bits/ios_base.h:39,
>>  from /usr/include/c++/4.8/ios:42,
>>  from /usr/include/c++/4.8/istream:38,
>>  from /usr/include/c++/4.8/sstream:38,
>>  from /usr/include/boost/test/utils/wrap_stringstream.hpp:26,
>>  from /usr/include/boost/test/predicate_result.hpp:20,
>>  from /usr/include/boost/test/test_tools.hpp:19,
>>  from /usr/include/boost/test/unit_test.hpp:19,
>>  from 
>> /«PKGBUILDDIR»/testsuite/supernova/sndfile_backend_test.cpp:1:
>> /«PKGBUILDDIR»/testsuite/supernova/sndfile_backend_test.cpp: In member 
>> function 'void sndfile_backend_test_1::test_method()':
>> /«PKGBUILDDIR»/testsuite/supernova/sndfile_backend_test.cpp:46:34: error: 
>> expected unqualified-id before numeric constant
>>  boost::xtime_get(&xt, boost::TIME_UTC);
>>   ^
>> In file included from 
>> /«PKGBUILDDIR»/external_libraries/nova-tt/nova-tt/semaphore.hpp:31:0,
>>  from 
>> /«PKGBUILDDIR»/server/supernova/audio_backend/sndfile_backend.hpp:31,
>>  from 
>> /«PKGBUILDDIR»/testsuite/supernova/sndfile_backend_test.cpp:4:
>> /«PKGBUILDDIR»/external_libraries/nova-tt/nova-tt/semaphore_posix.hpp: In 
>> instantiation of 'void nova::nova_tt::semaphore::post() 
>> [with bool has_timed_wait = false]':
>> /«PKGBUILDDIR»/server/supernova/audio_backend/sndfile_backend.hpp:142:30:   
>> required from 'void nova::sndfile_backend> blocking>::deactivate_audio() [with engine_functor = 
>> {anonymous}::engine_functor; sample_type = float; bool blocking = false]'
>> /«PKGBUILDDIR»/testsui

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

[Dan S]

2012/8/13 Felipe Sateler :
> On Sun, Aug 12, 2012 at 5:37 PM, Dan S  wrote:
>> 2012/8/12 peter green :
>>>>
>>>> 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.

[Dan S]

2012/8/12 peter green :
>>
>> 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#681187: fixed in supercollider 1:3.5.3~repack-2

[Dan S]

-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#679695: fixed in supercollider 1:3.5.3~repack-2

[Dan S]

2012/7/29 Dan S :
>


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681187: supercollider-emacs: unowned files after purge (policy 6.8, 10.8)

[Dan S]

2012/7/11 Andreas Beckmann :
> Package: supercollider-emacs
> Version: 1:3.5.3~repack-1
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8 (or 10.8):
>
> http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails
>
> Filing this as important as having a piuparts clean archive is a release
> goal since lenny.
>
> >From the attached log (scroll to the bottom...):
>
> 1m24.2s ERROR: FAIL: Package purging left files on system:
>   /usr/share/emacs23/site-lisp/  owned by: emacs23-common
>   /usr/share/emacs23/site-lisp/SuperCollider/not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-browser.elc  not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-dev.elc  not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-document.elc not 
> owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-help.elc not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-interp.elc   not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-keys.elc not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-language.elc not 
> owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-menu.elc not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-minor-mode.elc   not 
> owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-mode.elc not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-server.elc   not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-util.elc not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-vars.elc not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang-widgets.elc  not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/sclang.elc  not owned
>   /usr/share/emacs23/site-lisp/SuperCollider/tree-widget.elc not owned

Hi -

Thanks for the report. I believe this is fixed with a patch in git
[1], should be fixed in next release

Dan

[1] 




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#679229: src:supercollider: bouncing mail address for Dan Stowell

[Dan S]

2012/6/27 Felipe Sateler :
> On Wed, Jun 27, 2012 at 10:53 AM, IOhannes m zmoelnig  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 2012-06-27 15:02, Dan S wrote:
>>> Hi -
>>>
>>> Works for me. It's my email address. I received the original email
>>> no problem.
>>>
>>
>>
>> it's weird.
>> i can confirm that mx.sourceforge.net indeed gives an error when
>> trying to send emails to danstowell@u.s.n, whereas when i try to send
>> an email to myself (zmoelnig@u.s.n) it only gives me a greylisting reject.
>
> Dan, would you mind changing your address to the one you use on the list?

I really don't want to do that.

> The sourceforge mail service seems broken (I get rejects too).

Uh. There's a sourceforge setting to acept mail from outside or not. I
had set it to off so as to prevent spam.
So if I have to I will turn it on again, and accept spam plus debian messages...

Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#679229: src:supercollider: bouncing mail address for Dan Stowell

[Dan S]

Hi -

Works for me. It's my email address. I received the original email no problem.

Thanks
Dan


2012/6/27 Ansgar Burchardt :
> Source: supercollider
> X-Debbugs-Cc: fsate...@debian.org
>
> The address listed in Uploaders (and Changed-By for the last upload) for
> Dan Stowell bounces, see below.
>
> Ansgar
>
>  Original Message 
> Subject: Mail delivery failed: returning message to sender
> Date: Wed, 27 Jun 2012 10:06:50 +
> From: Mail Delivery System 
> To: envel...@ftp-master.debian.org
>
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>  danstow...@users.sourceforge.net
>    SMTP error from remote mail server after RCPT
> TO::
>    host mx.sourceforge.net [216.34.181.68]: 550 unknown user
>
> -- This is a copy of the message, including all the headers. --
>
> Return-path: 
> Received: from dak by franck.debian.org with local (Exim 4.72)
>        (envelope-from )
>        id 1Sjp8v-0001Gh-L2; Wed, 27 Jun 2012 10:06:37 +
> Date: Wed, 27 Jun 2012 10:06:37 +
> Message-Id: 
> From: Debian FTP Masters 
> To: Dan Stowell , Debian Multimedia
> Packages Maintainers
> , fsate...@debian.org
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: supercollider
> Precedence: bulk
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: supercollider_3.5.2-1_amd64.changes ACCEPTED into unstable
> Sender: Archive Administrator 
>
>
>
>
> Accepted:
> libscsynth1_3.5.2-1_amd64.deb
>  to main/s/supercollider/libscsynth1_3.5.2-1_amd64.deb
> supercollider-common_3.5.2-1_all.deb
>  to main/s/supercollider/supercollider-common_3.5.2-1_all.deb
> supercollider-dev_3.5.2-1_amd64.deb
>  to main/s/supercollider/supercollider-dev_3.5.2-1_amd64.deb
> supercollider-emacs_3.5.2-1_all.deb
>  to main/s/supercollider/supercollider-emacs_3.5.2-1_all.deb
> supercollider-gedit_3.5.2-1_all.deb
>  to main/s/supercollider/supercollider-gedit_3.5.2-1_all.deb
> supercollider-server_3.5.2-1_amd64.deb
>  to main/s/supercollider/supercollider-server_3.5.2-1_amd64.deb
> supercollider-supernova_3.5.2-1_amd64.deb
>  to main/s/supercollider/supercollider-supernova_3.5.2-1_amd64.deb
> supercollider-vim_3.5.2-1_all.deb
>  to main/s/supercollider/supercollider-vim_3.5.2-1_all.deb
> supercollider_3.5.2-1.debian.tar.gz
>  to main/s/supercollider/supercollider_3.5.2-1.debian.tar.gz
> supercollider_3.5.2-1.dsc
>  to main/s/supercollider/supercollider_3.5.2-1.dsc
> supercollider_3.5.2-1_amd64.deb
>  to main/s/supercollider/supercollider_3.5.2-1_amd64.deb
> supercollider_3.5.2.orig.tar.bz2
>  to main/s/supercollider/supercollider_3.5.2.orig.tar.bz2
>
>
> Changes:
> supercollider (1:3.5.2-1) unstable; urgency=low
>  .
>  * Imported Upstream version 3.5.2
>  * Add manpage for supernova
>  * Use system mathjax via dh_linktree
>  * Backport fix to vim plugin from upstream
>
>
> Override entries for your package:
> libscsynth1_3.5.2-1_amd64.deb - optional sound
> supercollider-common_3.5.2-1_all.deb - optional sound
> supercollider-dev_3.5.2-1_amd64.deb - optional sound
> supercollider-emacs_3.5.2-1_all.deb - optional sound
> supercollider-gedit_3.5.2-1_all.deb - optional sound
> supercollider-server_3.5.2-1_amd64.deb - optional sound
> supercollider-supernova_3.5.2-1_amd64.deb - optional sound
> supercollider-vim_3.5.2-1_all.deb - optional sound
> supercollider_3.5.2-1.dsc - source sound
> supercollider_3.5.2-1_amd64.deb - optional sound
>
> Announcing to debian-devel-chan...@lists.debian.org
>
>
> Thank you for your contribution to Debian.
>
> ___
> 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.

[Dan S]

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 :
> 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#648866: supercollider: FTBFS on powerpc

[Dan S]

2011/11/15 Michael Terry :
> Package: supercollider
> Version: 1:3.4.4-2
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu precise ubuntu-patch
>
> Dear Maintainer,
>
> In Ubuntu, supercollider is FTBFS on powerpc.  This seems to be an old 
> problem,
> mentioned on the sc-users mailing list in 2010.
>
> https://launchpadlibrarian.net/85153649/buildlog_ubuntu-precise-powerpc.supercollider_1%3A3.4.4-2ubuntu1_FAILEDTOBUILD.txt.gz
> http://www.listarc.bham.ac.uk/lists/sc-users-2008/msg62313.html
>
> I've include the patch from the mailing list in Ubuntu and it seems to fix the
> issue.
>
> Thanks for considering the patch.

Hi - thanks for reporting. Committed, and forwarded (back!) upstream

Dan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#648782: FTBFS due to undefined symbols

[Dan S]

2011/11/15 Mathieu Trudel-Lapierre :
> Package: supercollider
> Version: 1:3.4.4-2
>
> A recent rebuild test in Ubuntu for supercollider 1:3.4.4-2 shows that
> it fails to build [1], due to restrictions imposed at linking time:
>
> g++ -o build/sclang -Wl,-rpath-link,build -Wl,-rpath-link,/usr/lib
> -lreadline Source/lang/LangSource/cmdLineFuncs.o -Lbuild -lsclang
> build/libsclang.so: undefined reference to `cwiid_set_rumble'
> build/libsclang.so: undefined reference to `uregex_groupCount_44'
> build/libsclang.so: undefined reference to `rl_reset_line_state'
> build/libsclang.so: undefined reference to `rl_bind_key'
> build/libsclang.so: undefined reference to `cwiid_set_mesg_callback'
> build/libsclang.so: undefined reference to `rl_event_hook'
> build/libsclang.so: undefined reference to `rl_replace_line'
> build/libsclang.so: undefined reference to `u_charsToUChars_44'
> build/libsclang.so: undefined reference to `rl_set_keyboard_input_timeout'
> build/libsclang.so: undefined reference to `rl_redisplay'
> build/libsclang.so: undefined reference to `rl_crlf'
> build/libsclang.so: undefined reference to `cwiid_set_err'
> build/libsclang.so: undefined reference to `cwiid_set_led'
> build/libsclang.so: undefined reference to `cwiid_set_rpt_mode'
> build/libsclang.so: undefined reference to `rl_basic_word_break_characters'
> build/libsclang.so: undefined reference to `rl_readline_name'
> build/libsclang.so: undefined reference to `cwiid_close'
> build/libsclang.so: undefined reference to `readline'
> build/libsclang.so: undefined reference to `cwiid_enable'
> build/libsclang.so: undefined reference to `uregex_findNext_44'
> build/libsclang.so: undefined reference to `cwiid_open'
> build/libsclang.so: undefined reference to `uregex_start_44'
> build/libsclang.so: undefined reference to `add_history'
> build/libsclang.so: undefined reference to `uregex_open_44'
> build/libsclang.so: undefined reference to `uregex_end_44'
> build/libsclang.so: undefined reference to `cwiid_disable'
> build/libsclang.so: undefined reference to `uregex_setText_44'
> build/libsclang.so: undefined reference to `cwiid_get_id'
> collect2: ld returned 1 exit status
>
> Readline, libicu and cwiid do not appear to be linked against in the
> right order in the build process, which yields the undefined
> references above. The same error happens on all architectures we test
> [2] (amd64, i386, armel, powerpc), but I suspect it also comes up on
> the other architectures in Debian as well.
>
> Attached is a patch that resolves the issue, it would be helpful if
> you could include it in your package or review it.
>
> [1] 
> https://launchpadlibrarian.net/84969289/buildlog_ubuntu-precise-amd64.supercollider_1%3A3.4.4-2_FAILEDTOBUILD.txt.gz
> [2] https://launchpad.net/ubuntu/+source/supercollider/1:3.4.4-2

Hi -

Thanks for the patch, it looks good. I'm not on precise yet so can't
test your issue directly, but the patch makes sense and builds here.
Committing it to the debian-multimedia git, and will send upstream.

Thanks
Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#644977: [supercollider] please add 'swing' as dependency

[Dan S]

2011/10/11 Simon Wenner :
> Package: supercollider
> Version: 1:3.4.4-1
> Severity: normal
>
> Supercollider has an optional GUI to manage the server. It requires
> SwingOSC. Please add this dependency.
>
> http://sourceforge.net/projects/swingosc/

Hi -

SwingOSC is optional and is a separate project, and I don't believe it
has a debian package. I don't have time to do this packaging, and the
next version of supercollider (3.5) will have its own qt-based gui
system, so the need for this becomes less urgent. I'm marking this as
"wontfix" but if anyone wants to take this up please go ahead!

Best
Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#644976: [supercollider] server fails to start

[Dan S]

2011/10/11 Simon Wenner :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Ok,I see. Thanks for the quick reply.
>
> I tried it interactively and the error looks the same:
>
...
> sc3> s.boot;
>
> booting 57110
> localhost
> sc3> Cannot connect to server socket err = Connection refused
> Cannot connect to server socket

OK, I've tested this on a new install (on 32-bit rather than 64-bit,
but otherwise similar) and I definitely can't reproduce it. Here are
some reasons why the server might be unable to connect:
 * There might already be a copy of scsynth running (e.g. from a
previous attempt) -- use top/htop to check, or use "killall scsynth"
before trying again.
 * There might be some other service blocking the port (the port is
listed in the output, 57110) -- use netstat -a to check.
 * There might be some firewall program running or suchlike, or some
unusual network configuration (e.g. no 'localhost')?

If any of them turn out to be what's happening for you, please let us
know. If anyone else can reproduce please tell us.

Thanks
Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#644976: [supercollider] server fails to start

[Dan S]

Hi -

Firstly, it is better to start jackd manually - that's what sc users
normally do, and in particular for bug reports it would be clearer
because jackd's startup procedure doesn't have to be included in the
output. (It should work, though.)

But the more fundamental issue is that booting the server is
asynchronous, so if you run a script which contains "s.boot; s.quit;"
the language doesn't wait for it to boot before it sends a quit
message. The tutorial you're reading is probably assuming interactive
use rather than a batch script. So I'd be grateful if you could either
test interactively, running something like:

  s.boot;
  // then wait for a happy boot message, then:
  s.quit

or by using a script consisting of this:

  s.waitForBoot{s.quit}

(The waitForBoot message is a convenience method that starts the boot
and then creates a Task which waits until booted before executing the
function.)

Dan



2011/10/11 Simon Wenner :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Package: supercollider
> Version: 1:3.4.4-1
> Severity: important
>
> I'm unable to get any supercollider example file running. The server
> always fails to start. I tested different ports, started sclang as
> root and started jackd manually.
>
> My example sc input file (from the SC tutorial):
>
> s = Server(\myServer, NetAddr("127.0.0.1", 58009));
> s.boot;
> s.quit;
>
> Error Output:
>
> ~$ sclang sclang.test
> init_OSC
> compiling class library..
>    NumPrimitives = 548
>    compiling dir: '/usr/share/SuperCollider/SCClassLibrary'
>    compiling dir: '/usr/share/SuperCollider/Extensions'
>    pass 1 done
> numentries = 866038 / 10707624 = 0.081
>    4572 method selectors, 2342 classes
>    method table size 12713944 bytes, big table size 85660992
>    Number of Symbols 11134
>    Byte Code Size 349335
>    compiled 362 files in 0.53 seconds
> compile done
> Help tree read from cache in 0.0093131065368652 seconds
> LID: event loop started
> Class tree inited in 0.03 seconds
> WARNING:
> GUI.fromID : The GUI scheme 'swing' is not installed
> The current scheme is still 'nil'!
> Welcome to SuperCollider, for help type ctrl-c ctrl-h (Emacs) or
> :SChelp (vim) or ctrl-U (sced/gedit)
> booting 58009
> /quit sent
>
> Cannot connect to server socket err = Connection refused
> Cannot connect to server socket
> no message buffer overruns
> no message buffer overruns
> jackdmp 1.9.7
> Copyright 2001-2005 Paul Davis and others.
> Copyright 2004-2011 Grame.
> jackdmp comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
> JACK server starting in realtime mode with priority 10
> control device hw:0
> control device hw:0
> audio_reservation_init
> Acquire audio card Audio0
> creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
> control device hw:0
> configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2
> periods
> ALSA: final selected sample format for capture: 32bit integer
> little-endian
> ALSA: use 2 periods for capture
> ALSA: final selected sample format for playback: 32bit integer
> little-endian
> ALSA: use 2 periods for playback
> JackProcessSync::LockedTimedWait error usec = 500 err = Connection
> timed out
> Driver is not running
> Cannot create new client
> JackSocketClientChannel read fail
> Cannot open SuperCollider client
> could not initialize audio.
> jackd: ../common/JackGraphManager.cpp:45: void
> Jack::JackGraphManager::AssertPort(jack_port_id_t): Assertion
> `port_index < fPortMax' failed.
> RESULT = 1
> ERROR:
> server failed to start
>
>
> - --- System information. ---
> Architecture: amd64
> Kernel: Linux 3.0.0-1-amd64
>
> Debian Release: wheezy/sid
> 990 testing security.debian.org
> 990 testing mirror.switch.ch
> 800 unstable mirror.switch.ch
> 150 experimental mirror.switch.ch
>
> - --- Package information. ---
> Depends (Version) | Installed
> ==-+-==
> libc6 (>= 2.2.5) | 2.13-21
> libgcc1 (>= 1:4.1.1) | 1:4.6.1-4
> libreadline6 (>= 6.0) | 6.2-4
> libsclang1 | 1:3.4.4-1
> libstdc++6 (>= 4.1.1) | 4.6.1-4
> supercollider-common (= 1:3.4.4-1) | 1:3.4.4-1
> supercollider-server | 1:3.4.4-1
>
>
> Package's Recommends field is empty.
>
> Suggests (Version) | Installed
> -+-===
> subversion | 1.6.17dfsg-1
> supercollider-doc | 1:3.4.4-1
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJOlBvMAAoJEMMF4eNtCPQViOQQAL8XudwmGZ+KSF1PwZrnAXaS
> VCoUzqIY08c7QxSyDlrqHOBYVybSo8hf1a1317dfzFPVK4uCTYzfUZgbSSLyuuaJ
> MgfAgD1LJsU6PFHuOPB2BF7NoUfZUoM2W06jRquymQ3PC3oR2V9WSofuAa3UnYpe
> BV2uns1+vbnXQtaW9jOFxqdADbMJ8aTtj/qoGQvvvGUh9CnEpb9x4HlT6McmW3Wh
> hJCqqG6IUt5G/W3FFVlpses7DG4+kNPSOyUyRDdYyhAiaTaoJt0+1Sb65NvZytY1
> 6XcPLKhl72MT3LTYY6VwAc41ugB7NzWff/rfw8LP5cjvDd+l/srof8WXlpvDVHZB
> id+6EaLoa

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/6/11 Jonas Smedegaard :
> On 11-06-11 at 03:07pm, Dan S wrote:
>> It would be great if others can comment - anyone?
>
> I've updated debian/copyright.  Please check the FIXMEs in that file!

Thanks - a couple of questions:

* The PNG images in the help system are under the same CC license as
the HTML help files. (They were not externally sourced.) They're
already covered by the "common/build/Help/*" entry. Why mark them as
unknown?

* Files: common/Source/plugins/FilterUGens.cpp is marked as "GPL-2+
and UNKNOWN", I guess because it includes code ported from Java code
by Federico Fontana. It was me that did the porting, and Federico gave
me permission to include it in this GPL-2+ software. So there's no
unknown licensing, but are you expecting some documentation or or
something?

* Also, you've allocated copyright of some associated files to
Federico Fontana (MoogFF.sc, MoogFF.html) yet he has no copyright in
those - I wrote them, they are not ported. So I can simply delete
those fixme entries, OK?


Most of the other stuff is just sloppy notices, which I'll try to get
fixed upstream.

Dan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/6/12 Dan S :
> 2011/6/11 Jonas Smedegaard :
>> On 11-06-11 at 03:07pm, Dan S wrote:
>>> It would be great if others can comment - anyone?
>>
>> I did a quick look (don't expect much involvement - am involved in too
>> much at the moment already, and have some deadlines in RL too).
>
> Thanks very much for these comments.
>
>> This looks bad:
>>
>>> # The build system apparently can't handle this
>>> CXXFLAGS =
>>
>> That and the DEB_SCONS_OPTIONS above it seems to indicate that it does
>> not follow Debian Policy §4.9.1. Only a recommendation apparently, but I
>> am uncertain if that only is _how_ to do it (i.e. DEB_BUILD_OPTIONS
>> hinting) while the underlying mechanisms (e.g. ability to build without
>> optimizations or without stripping binaries) is a must.
>
> This is reasonable -- there's about to be a minor upstream release so
> I'll try and patch upstream (even though it's a debianny issue), to
> parse DEB_BUILD_OPTIONS.

My mistake, it's not upstream, it's in the rules file.

>> The -doc package should probably suggest the main package.  Similarly
>> for the editor plugin packages (suggestions are too weak to cause a
>> "domino effect" so are in my opinion best to declare explicitly).
>
> OK
>
>
>> Oh, and why do editor plugins recommend -doc package?  Seems they are
>> tools to write code, not closely related to the documentation of the
>> tool, so should perhaps be lowered to a suggestion.
>
> I see your reasoning. Well, the documentation is not completely
> independent - the editor-plugins include "jump to the help for this
> command"-type features, and if the -doc is missing we get confused
> users asking why the help-feature is broken. My inclination is for
> Recommends here, for that reason - sounds OK?
>
>
>> And I guess main packages not suggest/recommend -doc package too.
>
> Sorry, what do you mean? You're saying perhaps that supercollider
> should Suggest supercollider-doc? That sounds sensible.
>
>
>> What is the most proper build-dependency for jack these days?  Here it
>> is "libjack-dev (>= 0.100) | libjack-jackd2-dev", which as I believe is
>> not wrong but seem to recall can be satisfied by a simpler dependency.
>
> Ah right, the version 2 package is marked as "Provides: libjack-dev"
> so we can simplify the dependency to "libjack-dev (>= 0.100)". I
> remember there being a reason for keeping both - but it might have
> been for earlier versions, before that particular "Provides" was in
> place.
>
>
>> The clean rule does not fully cleanup.  These files was left behind:
>>
>>  common/.sconf_temp/
>>  common/.sconsign.dblite
>>  common/config.log
>
> I don't see this behaviour. (The clean rule contains an explicit "rm
> -f common/.sconsign.dblite" so I'm not sure how it would happen.)
> Could you give me the full commands to reproduce please?
>
>
>> I will do an analysis on copyrights/licenses now - and hope not to find
>> anything controversial there
>
> Thanks
>
> Dan
>
>
>> Regards,
>>
>>  - Jonas
>>
>> --
>>  * Jonas Smedegaard - idealist & Internet-arkitekt
>>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>>
>>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>>
>> ___
>> 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#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/6/11 Jonas Smedegaard :
> On 11-06-11 at 03:07pm, Dan S wrote:
>> It would be great if others can comment - anyone?
>
> I did a quick look (don't expect much involvement - am involved in too
> much at the moment already, and have some deadlines in RL too).

Thanks very much for these comments.

> This looks bad:
>
>> # The build system apparently can't handle this
>> CXXFLAGS =
>
> That and the DEB_SCONS_OPTIONS above it seems to indicate that it does
> not follow Debian Policy §4.9.1. Only a recommendation apparently, but I
> am uncertain if that only is _how_ to do it (i.e. DEB_BUILD_OPTIONS
> hinting) while the underlying mechanisms (e.g. ability to build without
> optimizations or without stripping binaries) is a must.

This is reasonable -- there's about to be a minor upstream release so
I'll try and patch upstream (even though it's a debianny issue), to
parse DEB_BUILD_OPTIONS.


> The -doc package should probably suggest the main package.  Similarly
> for the editor plugin packages (suggestions are too weak to cause a
> "domino effect" so are in my opinion best to declare explicitly).

OK


> Oh, and why do editor plugins recommend -doc package?  Seems they are
> tools to write code, not closely related to the documentation of the
> tool, so should perhaps be lowered to a suggestion.

I see your reasoning. Well, the documentation is not completely
independent - the editor-plugins include "jump to the help for this
command"-type features, and if the -doc is missing we get confused
users asking why the help-feature is broken. My inclination is for
Recommends here, for that reason - sounds OK?


> And I guess main packages not suggest/recommend -doc package too.

Sorry, what do you mean? You're saying perhaps that supercollider
should Suggest supercollider-doc? That sounds sensible.


> What is the most proper build-dependency for jack these days?  Here it
> is "libjack-dev (>= 0.100) | libjack-jackd2-dev", which as I believe is
> not wrong but seem to recall can be satisfied by a simpler dependency.

Ah right, the version 2 package is marked as "Provides: libjack-dev"
so we can simplify the dependency to "libjack-dev (>= 0.100)". I
remember there being a reason for keeping both - but it might have
been for earlier versions, before that particular "Provides" was in
place.


> The clean rule does not fully cleanup.  These files was left behind:
>
>  common/.sconf_temp/
>  common/.sconsign.dblite
>  common/config.log

I don't see this behaviour. (The clean rule contains an explicit "rm
-f common/.sconsign.dblite" so I'm not sure how it would happen.)
Could you give me the full commands to reproduce please?


> I will do an analysis on copyrights/licenses now - and hope not to find
> anything controversial there

Thanks

Dan


> Regards,
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> ___
> 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#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/5/17 Felipe Sateler :
> On Mon, May 16, 2011 at 09:04, Dan S  wrote:
>> 2011/5/15 Felipe Sateler :
>>> On Thu, May 12, 2011 at 06:07, Dan S  wrote:
>>>> 2011/5/11 Felipe Sateler :
>>>>> Hi, sorry for taking so long.
>>>>>
>>>>> On Fri, Apr 29, 2011 at 15:57, Dan S  wrote:
>>>>>> 2011/4/16 Felipe Sateler :
>>>>>>
>>>>>>> - I would really like to fold all the -dev packages into one. I don't
>>>>>>> see much point in splitting them.
>>>>>>
>>>>>> I've discussed it with the upstream devs and we're OK with merging
>>>>>> them, so I've done that.
>>>>>
>>>>> Good. However, the relationship with thte old packages is wrong. It
>>>>> should Replace the older packages.
>>>>
>>>> Ah right, thanks.
>>>>
>>>>> However, I'm not quite sure if we
>>>>> should apply policy 7.6.1 or 7.6.2 (ie, Replaces+Breaks or
>>>>> Replaces+Conflicts+Provides).
>>>>>
>>>>> What do others think?
>>>>
>>>> In lieu of any other responses (so far), the latter
>>>> (Replaces+Conflicts+Provides) seems to me to have the better
>>>> semantics, although we're not talking about virtual packages (which
>>>> policy 7.5 is pretty specific about). From reading the guide I can't
>>>> decide either; unless anyone can advise, maybe we should go for
>>>> Replaces+Breaks.
>>>
>>> Upon further reading, I think we should use
>>> conflicts+replaces+provides, because we are replacing whole packages.
>>
>> OK, done.
>
> I probably won't be able to dedicate much time to this during this
> week, so if anyone else can have a look at this package and comment on
> it, I'd appreciate it. I'd like to have more eyeballs looking at it
> since it is not a trivial package and I could have missed some things.

I'm very grateful for your help in polishing up this package (indeed,
non-trivial). It would be great if others can comment - anyone?
And if not, what are the next steps?

Thanks
Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/5/15 Felipe Sateler :
> On Thu, May 12, 2011 at 06:07, Dan S  wrote:
>> 2011/5/11 Felipe Sateler :
>>> Hi, sorry for taking so long.
>>>
>>> On Fri, Apr 29, 2011 at 15:57, Dan S  wrote:
>>>> 2011/4/16 Felipe Sateler :
>>>>
>>>>> - I would really like to fold all the -dev packages into one. I don't
>>>>> see much point in splitting them.
>>>>
>>>> I've discussed it with the upstream devs and we're OK with merging
>>>> them, so I've done that.
>>>
>>> Good. However, the relationship with thte old packages is wrong. It
>>> should Replace the older packages.
>>
>> Ah right, thanks.
>>
>>> However, I'm not quite sure if we
>>> should apply policy 7.6.1 or 7.6.2 (ie, Replaces+Breaks or
>>> Replaces+Conflicts+Provides).
>>>
>>> What do others think?
>>
>> In lieu of any other responses (so far), the latter
>> (Replaces+Conflicts+Provides) seems to me to have the better
>> semantics, although we're not talking about virtual packages (which
>> policy 7.5 is pretty specific about). From reading the guide I can't
>> decide either; unless anyone can advise, maybe we should go for
>> Replaces+Breaks.
>
> Upon further reading, I think we should use
> conflicts+replaces+provides, because we are replacing whole packages.

OK, done.

Best
Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/5/11 Felipe Sateler :
> Hi, sorry for taking so long.
>
> On Fri, Apr 29, 2011 at 15:57, Dan S  wrote:
>> 2011/4/16 Felipe Sateler :
>>
>>> - I would really like to fold all the -dev packages into one. I don't
>>> see much point in splitting them.
>>
>> I've discussed it with the upstream devs and we're OK with merging
>> them, so I've done that.
>
> Good. However, the relationship with thte old packages is wrong. It
> should Replace the older packages.

Ah right, thanks.

> However, I'm not quite sure if we
> should apply policy 7.6.1 or 7.6.2 (ie, Replaces+Breaks or
> Replaces+Conflicts+Provides).
>
> What do others think?

In lieu of any other responses (so far), the latter
(Replaces+Conflicts+Provides) seems to me to have the better
semantics, although we're not talking about virtual packages (which
policy 7.5 is pretty specific about). From reading the guide I can't
decide either; unless anyone can advise, maybe we should go for
Replaces+Breaks.

Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/4/16 Felipe Sateler :
> On Fri, Apr 15, 2011 at 18:45, Dan S  wrote:
>> 2011/4/15 Felipe Sateler :
>>> On Fri, Apr 15, 2011 at 09:40, Dan S  wrote:
>>>
>>>>>> I've tried to import 3.4.3 onto a clean repository (using
>>>>>> git-import-orig) and it hit a merge conflict.
>>>>>>
>>>>>> A log of my session is at <http://pastie.org/1792082> - I'd be
>>>>>> grateful for any advice on whatever might have gone wrong. Am I using
>>>>>> git-import-orig as intended?
>>>>>
>>>>> Yes. But the borked import of 3.4.2  breaks it. Try first merging from
>>>>> the upstream branch and then using git-import-orig.
>>>>
>>>> Ah, now I see. OK it works now, and all is looking good. My local git
>>>> history (on master) now looks like
>>>> http://pastie.org/1797302
>>>>
>>>> Please let me know if it looks like the right things have happened -
>>>> then I'll push.
>>>
>>> Looks good to  me.
>>
>> OK pushed, thanks.
>
> Some more comments:
>
> - Do we really want an empty Extensions dir in the supercollider
> package? What purpose does it serve?

It's the place where users will place extensions (both server plugins
and language extensions). For usability purposes I think it's better
to have this rather than to expect people to create it (they may
misspell it, etc). It's inside SuperCollider's own folder
/usr/share/SuperCollider rather than cluttering anywhere else, so I'd
argue it's not a problem.


> - I would really like to fold all the -dev packages into one. I don't
> see much point in splitting them.

I've discussed it with the upstream devs and we're OK with merging
them, so I've done that.

Best,
Dan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/4/15 Felipe Sateler :
> On Wed, Apr 13, 2011 at 14:58, Dan S  wrote:
>> 2011/4/10 Dan S :
>>> 2011/4/10 Felipe Sateler :
>>>> On Sun, Apr 10, 2011 at 04:34, Dan S  wrote:
>>>>>>>>> ...and now SC 3.4.2 has been released on the same day. So I've
>>>>>>>>> imported it into the git (3 patches no longer needed, hooray) - all
>>>>>>>>> testing and feedback welcome.
>>>>>>>>
>>>>>>>>
>>>>>>>> Looks like you didn't actually merge the upstream branch into master
>>>>>>>> but instead imported the new tarball as a new commit.
>>>>>>>
>>>>>>> I used git-import-orig, surely that's the right thing to do?
>>>>>>> <http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.NEW.UPSTREAM>
>>>>>>
>>>>>> Hmm, it seems to have done a broken import. Did it actually succeed in
>>>>>> the merge?
>>>>>
>>>>> Yes it did. If there's anything I should do that can fix this, please
>>>>> let me know.
>>>>>
>>>>> There will be a version 3.4.3 out fairly soon (3.4.2 has a
>>>>> regression!) so I'll need to know how to import it right.
>>>>
>>>> Hmm, I usually just call git-import-orig on the tarball and all the
>>>> magic is done. I'm not sure what could have gone wrong.
>>>>
>>>> If 3.4.3 will be out soon, then maybe we can let this one go and do
>>>> the 3.4.3 on right instead.
>>>
>>> OK, well I'll do it the same way when 3.4.3 is out, but I'll do a test
>>> run and try to make sure the commits are as expected before pushing!
>>
>> I've tried to import 3.4.3 onto a clean repository (using
>> git-import-orig) and it hit a merge conflict.
>>
>> A log of my session is at <http://pastie.org/1792082> - I'd be
>> grateful for any advice on whatever might have gone wrong. Am I using
>> git-import-orig as intended?
>
> Yes. But the borked import of 3.4.2  breaks it. Try first merging from
> the upstream branch and then using git-import-orig.

Ah, now I see. OK it works now, and all is looking good. My local git
history (on master) now looks like
http://pastie.org/1797302

Please let me know if it looks like the right things have happened -
then I'll push.

Thanks
Dan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/4/10 Dan S :
> 2011/4/10 Felipe Sateler :
>> On Sun, Apr 10, 2011 at 04:34, Dan S  wrote:
>>>>>>> ...and now SC 3.4.2 has been released on the same day. So I've
>>>>>>> imported it into the git (3 patches no longer needed, hooray) - all
>>>>>>> testing and feedback welcome.
>>>>>>
>>>>>>
>>>>>> Looks like you didn't actually merge the upstream branch into master
>>>>>> but instead imported the new tarball as a new commit.
>>>>>
>>>>> I used git-import-orig, surely that's the right thing to do?
>>>>> <http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.NEW.UPSTREAM>
>>>>
>>>> Hmm, it seems to have done a broken import. Did it actually succeed in
>>>> the merge?
>>>
>>> Yes it did. If there's anything I should do that can fix this, please
>>> let me know.
>>>
>>> There will be a version 3.4.3 out fairly soon (3.4.2 has a
>>> regression!) so I'll need to know how to import it right.
>>
>> Hmm, I usually just call git-import-orig on the tarball and all the
>> magic is done. I'm not sure what could have gone wrong.
>>
>> If 3.4.3 will be out soon, then maybe we can let this one go and do
>> the 3.4.3 on right instead.
>
> OK, well I'll do it the same way when 3.4.3 is out, but I'll do a test
> run and try to make sure the commits are as expected before pushing!

I've tried to import 3.4.3 onto a clean repository (using
git-import-orig) and it hit a merge conflict.

A log of my session is at <http://pastie.org/1792082> - I'd be
grateful for any advice on whatever might have gone wrong. Am I using
git-import-orig as intended?

Thanks
Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/4/10 Felipe Sateler :
> On Sun, Apr 10, 2011 at 04:34, Dan S  wrote:
>> 2011/4/10 Felipe Sateler :
>>> On Mon, Apr 4, 2011 at 03:06, Dan S  wrote:
>>>> 2011/4/4 Felipe Sateler :
>>>>> On Mon, Mar 28, 2011 at 18:42, Dan S  wrote:
>>>>>> 2011/3/28 Dan S :
>>>>>>> 2011/3/28 Felipe Sateler :
>>>>>>>>>>> I've pushed a commit to that branch that apparently solves the 
>>>>>>>>>>> issue.
>>>>>>>>>>
>>>>>>>>>> Great, works here, thanks.
>>>>>>>>>>
>>>>>>>>>> Someone else started the supercollider packaging (on ubuntu) and he
>>>>>>>>>> had reasons for going with --install-sandbox. He is bcc'ed here -
>>>>>>>>>> Artem please send me (or deb-mm) a mail if you have objections.
>>>>>>>>>>
>>>>>>>>>> I'll merge that branch into master, and send the change upstream (for
>>>>>>>>>> inclusion in 3.4.2).
>>>>>>>>>
>>>>>>>>> Remember to include the change in master as a patch instead of
>>>>>>>>> directly modifying SConstruct!
>>>>>>>>
>>>>>>>> Ping?
>>>>>>>
>>>>>>> Thanks for the nudge - now committed. Any feedback welcome - this was
>>>>>>> the first time I used quilt "properly"
>>>>>>
>>>>>> ...and now SC 3.4.2 has been released on the same day. So I've
>>>>>> imported it into the git (3 patches no longer needed, hooray) - all
>>>>>> testing and feedback welcome.
>>>>>
>>>>>
>>>>> Looks like you didn't actually merge the upstream branch into master
>>>>> but instead imported the new tarball as a new commit.
>>>>
>>>> I used git-import-orig, surely that's the right thing to do?
>>>> <http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.NEW.UPSTREAM>
>>>
>>> Hmm, it seems to have done a broken import. Did it actually succeed in
>>> the merge?
>>
>> Yes it did. If there's anything I should do that can fix this, please
>> let me know.
>>
>> There will be a version 3.4.3 out fairly soon (3.4.2 has a
>> regression!) so I'll need to know how to import it right.
>
> Hmm, I usually just call git-import-orig on the tarball and all the
> magic is done. I'm not sure what could have gone wrong.
>
> If 3.4.3 will be out soon, then maybe we can let this one go and do
> the 3.4.3 on right instead.

OK, well I'll do it the same way when 3.4.3 is out, but I'll do a test
run and try to make sure the commits are as expected before pushing!


> On to more general comments:
>
> - Shared libraries have to be on a package of their own. See policy
> section 8. For this package it means we need new binary packages
> called libsclang1 and libscsynth1 with the shared library. The .so
> symlinks should go in the dev package.

OK, done this, but lintian tells me:

W: libsclang1: package-name-doesnt-match-sonames libsclang1.0.0
W: libscsynth1: package-name-doesnt-match-sonames libscsynth1.0.0

Not sure what to do from here, whether the package name needs the
decimals (yuck) or the soname needs to lose the decimals (& do we then
need another soflink libsclang1->libsclang1.0.0)?


> - Is the sc-common-dev and sc-dev split really necessary?

It has a purpose: sc-dev is the dev files for working with the
language API, which would be irrelevant for someone doing work with
the server (e.g. a plugin). However, it might be worth thinking about
lumping them all together since after all it's just some header files
- I'll mention it to the devs and see what we think.


> - Add yourself to th Uploaders field.

OK

Thanks
Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/4/10 Felipe Sateler :
> On Mon, Apr 4, 2011 at 03:06, Dan S  wrote:
>> 2011/4/4 Felipe Sateler :
>>> On Mon, Mar 28, 2011 at 18:42, Dan S  wrote:
>>>> 2011/3/28 Dan S :
>>>>> 2011/3/28 Felipe Sateler :
>>>>>>>>> I've pushed a commit to that branch that apparently solves the issue.
>>>>>>>>
>>>>>>>> Great, works here, thanks.
>>>>>>>>
>>>>>>>> Someone else started the supercollider packaging (on ubuntu) and he
>>>>>>>> had reasons for going with --install-sandbox. He is bcc'ed here -
>>>>>>>> Artem please send me (or deb-mm) a mail if you have objections.
>>>>>>>>
>>>>>>>> I'll merge that branch into master, and send the change upstream (for
>>>>>>>> inclusion in 3.4.2).
>>>>>>>
>>>>>>> Remember to include the change in master as a patch instead of
>>>>>>> directly modifying SConstruct!
>>>>>>
>>>>>> Ping?
>>>>>
>>>>> Thanks for the nudge - now committed. Any feedback welcome - this was
>>>>> the first time I used quilt "properly"
>>>>
>>>> ...and now SC 3.4.2 has been released on the same day. So I've
>>>> imported it into the git (3 patches no longer needed, hooray) - all
>>>> testing and feedback welcome.
>>>
>>>
>>> Looks like you didn't actually merge the upstream branch into master
>>> but instead imported the new tarball as a new commit.
>>
>> I used git-import-orig, surely that's the right thing to do?
>> <http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.NEW.UPSTREAM>
>
> Hmm, it seems to have done a broken import. Did it actually succeed in
> the merge?

Yes it did. If there's anything I should do that can fix this, please
let me know.

There will be a version 3.4.3 out fairly soon (3.4.2 has a
regression!) so I'll need to know how to import it right.

> Also, please push the upstream tag too.

Ah, sorry, now done.

Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/4/4 Felipe Sateler :
> On Mon, Mar 28, 2011 at 18:42, Dan S  wrote:
>> 2011/3/28 Dan S :
>>> 2011/3/28 Felipe Sateler :
>>>>>>> I've pushed a commit to that branch that apparently solves the issue.
>>>>>>
>>>>>> Great, works here, thanks.
>>>>>>
>>>>>> Someone else started the supercollider packaging (on ubuntu) and he
>>>>>> had reasons for going with --install-sandbox. He is bcc'ed here -
>>>>>> Artem please send me (or deb-mm) a mail if you have objections.
>>>>>>
>>>>>> I'll merge that branch into master, and send the change upstream (for
>>>>>> inclusion in 3.4.2).
>>>>>
>>>>> Remember to include the change in master as a patch instead of
>>>>> directly modifying SConstruct!
>>>>
>>>> Ping?
>>>
>>> Thanks for the nudge - now committed. Any feedback welcome - this was
>>> the first time I used quilt "properly"
>>
>> ...and now SC 3.4.2 has been released on the same day. So I've
>> imported it into the git (3 patches no longer needed, hooray) - all
>> testing and feedback welcome.
>
>
> Looks like you didn't actually merge the upstream branch into master
> but instead imported the new tarball as a new commit.

I used git-import-orig, surely that's the right thing to do?
<http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.NEW.UPSTREAM>

Dan

> Any ideas on how to fix this? One could revert the commit and do a
> proper merge, I guess. Any other options?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/3/28 Dan S :
> 2011/3/28 Felipe Sateler :
>>>>> I've pushed a commit to that branch that apparently solves the issue.
>>>>
>>>> Great, works here, thanks.
>>>>
>>>> Someone else started the supercollider packaging (on ubuntu) and he
>>>> had reasons for going with --install-sandbox. He is bcc'ed here -
>>>> Artem please send me (or deb-mm) a mail if you have objections.
>>>>
>>>> I'll merge that branch into master, and send the change upstream (for
>>>> inclusion in 3.4.2).
>>>
>>> Remember to include the change in master as a patch instead of
>>> directly modifying SConstruct!
>>
>> Ping?
>
> Thanks for the nudge - now committed. Any feedback welcome - this was
> the first time I used quilt "properly"

...and now SC 3.4.2 has been released on the same day. So I've
imported it into the git (3 patches no longer needed, hooray) - all
testing and feedback welcome.

Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/3/28 Felipe Sateler :
 I've pushed a commit to that branch that apparently solves the issue.
>>>
>>> Great, works here, thanks.
>>>
>>> Someone else started the supercollider packaging (on ubuntu) and he
>>> had reasons for going with --install-sandbox. He is bcc'ed here -
>>> Artem please send me (or deb-mm) a mail if you have objections.
>>>
>>> I'll merge that branch into master, and send the change upstream (for
>>> inclusion in 3.4.2).
>>
>> Remember to include the change in master as a patch instead of
>> directly modifying SConstruct!
>
> Ping?

Thanks for the nudge - now committed. Any feedback welcome - this was
the first time I used quilt "properly"

Dan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/3/8 Felipe Sateler :
> On Wed, Mar 2, 2011 at 23:32, Dan S  wrote:
>> 2011/2/25 Felipe Sateler :
>>> On Sun, Feb 20, 2011 at 20:59, Felipe Sateler  wrote:
>>>> On Sat, Feb 19, 2011 at 17:46, Dan S  wrote:
>>>>> 2010/10/31 Felipe Sateler :
>>>>>> Package: wnpp
>>>>>> Severity: wishlist
>>>>>> Owner: pkg-multimedia-maintain...@lists.alioth.debian.org
>>>>>>
>>>>>> * Package name    : supercollider
>>>>>>  Version         : 3.4
>>>>>>  Upstream Author : Lots of people
>>>>>> * URL             : http://supercollider.sourceforge.net
>>>>>> * License         : mostly GPL, some BSD, CC-BY-SA-3.0
>>>>>>  Programming Lang: C++
>>>>>>  Description     : A real time audio synthesis programming language
>>>>>>
>>>>>> SuperCollider is an environment and programming language for real time
>>>>>> audio synthesis and algorithmic composition. It provides an interpreted
>>>>>> object-oriented language which functions as a network client
>>>>>> to a state of the art, realtime sound synthesis server.
>>>>>
>>>>> OK, status of the supercollider packaging. Here's what I wrote on 4th
>>>>> jan (re a patch to add versioning to the soname):
>>>>>
>>>>>> The patch is in, upstream. What's happening right now is we're
>>>>>> preparing a 3.4.2 release, which will include this patch. (release
>>>>>> candidate files are at
>>>>>> <http://sourceforge.net/projects/supercollider/files/Source/3.4.2/>)
>>>>>>
>>>>>> The neatest thing is to wait for 3.4.2 official release, then import
>>>>>> it to the deb-mm repo and tweak the scripts for .so.1. Should be soon!
>>>>>
>>>>> Since then, there's been some delay in supercolliderland due to
>>>>> debating garbage-collection issues in the development branch. We can
>>>>> either wait more, or apply the patch downstream, in which case it
>>>>> would I think be ready for others to try? What's the next step once
>>>>> we're OK with the packaging?
>>>>
>>>> Since the patch is already applied upstream, and we are likely to wait
>>>> a while before 3.4.2 is out, it should be OK to apply the patch
>>>> locally to 3.4.1 for now. Please do that, and update the packaging
>>>> accordingly.
>>>
>>> Ping?
>>
>> OK I've had a look at this tonight. There is a scons problem, which
>> lintian handily discovers for me. (Hooray lintian! I think.)
>>
>> The patched build script creates symlinks such as
>> libscsynth.so->libscsynth.so.1.0.0. However, when scons is installing,
>> it doesn't install a symlink but copies the file contents. Therefore
>> instead of one lib file and one symlink, we get two identical lib
>> files - and lintian correctly reports this as an error.
>>
>> I've been trying to find a way to convince scons to do the right
>> thing. I pushed an experimental branch to the git named
>> "scons_soversion" where instead of creating a symlink and asking scons
>> to install it, we add a symlinking command that should run during
>> installation. The problem is, that scons (v1.2.0) uses python chdir()
>> when running commands, which jumps it straight out of the DESTDIR and
>> tries to install in the system /usr/lib rather than the current build
>> tree. So I can't find a way of getting scons to create the symlink
>> during the install step AND inside DESTDIR. One or the other but not
>> both.
>>
>> If anyone can offer suggestions I'd be grateful.
>> http://git.debian.org/?p=pkg-multimedia/supercollider.git;a=shortlog;h=refs/heads/scons_soversion
>
> It seems to me that the problem you are having is because your
> debian/rules uses the --install-sandbox option instead of the
> handcoded (by upstream) DESTDIR variable handling in SConstruct.

Interesting...

> I've pushed a commit to that branch that apparently solves the issue.

Great, works here, thanks.

Someone else started the supercollider packaging (on ubuntu) and he
had reasons for going with --install-sandbox. He is bcc'ed here -
Artem please send me (or deb-mm) a mail if you have objections.

I'll merge that branch into master, and send the change upstream (for
inclusion in 3.4.2).

Thanks
Dan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/2/25 Felipe Sateler :
> On Sun, Feb 20, 2011 at 20:59, Felipe Sateler  wrote:
>> On Sat, Feb 19, 2011 at 17:46, Dan S  wrote:
>>> 2010/10/31 Felipe Sateler :
>>>> Package: wnpp
>>>> Severity: wishlist
>>>> Owner: pkg-multimedia-maintain...@lists.alioth.debian.org
>>>>
>>>> * Package name    : supercollider
>>>>  Version         : 3.4
>>>>  Upstream Author : Lots of people
>>>> * URL             : http://supercollider.sourceforge.net
>>>> * License         : mostly GPL, some BSD, CC-BY-SA-3.0
>>>>  Programming Lang: C++
>>>>  Description     : A real time audio synthesis programming language
>>>>
>>>> SuperCollider is an environment and programming language for real time
>>>> audio synthesis and algorithmic composition. It provides an interpreted
>>>> object-oriented language which functions as a network client
>>>> to a state of the art, realtime sound synthesis server.
>>>
>>> OK, status of the supercollider packaging. Here's what I wrote on 4th
>>> jan (re a patch to add versioning to the soname):
>>>
>>>> The patch is in, upstream. What's happening right now is we're
>>>> preparing a 3.4.2 release, which will include this patch. (release
>>>> candidate files are at
>>>> <http://sourceforge.net/projects/supercollider/files/Source/3.4.2/>)
>>>>
>>>> The neatest thing is to wait for 3.4.2 official release, then import
>>>> it to the deb-mm repo and tweak the scripts for .so.1. Should be soon!
>>>
>>> Since then, there's been some delay in supercolliderland due to
>>> debating garbage-collection issues in the development branch. We can
>>> either wait more, or apply the patch downstream, in which case it
>>> would I think be ready for others to try? What's the next step once
>>> we're OK with the packaging?
>>
>> Since the patch is already applied upstream, and we are likely to wait
>> a while before 3.4.2 is out, it should be OK to apply the patch
>> locally to 3.4.1 for now. Please do that, and update the packaging
>> accordingly.
>
> Ping?

OK I've had a look at this tonight. There is a scons problem, which
lintian handily discovers for me. (Hooray lintian! I think.)

The patched build script creates symlinks such as
libscsynth.so->libscsynth.so.1.0.0. However, when scons is installing,
it doesn't install a symlink but copies the file contents. Therefore
instead of one lib file and one symlink, we get two identical lib
files - and lintian correctly reports this as an error.

I've been trying to find a way to convince scons to do the right
thing. I pushed an experimental branch to the git named
"scons_soversion" where instead of creating a symlink and asking scons
to install it, we add a symlinking command that should run during
installation. The problem is, that scons (v1.2.0) uses python chdir()
when running commands, which jumps it straight out of the DESTDIR and
tries to install in the system /usr/lib rather than the current build
tree. So I can't find a way of getting scons to create the symlink
during the install step AND inside DESTDIR. One or the other but not
both.

If anyone can offer suggestions I'd be grateful.
http://git.debian.org/?p=pkg-multimedia/supercollider.git;a=shortlog;h=refs/heads/scons_soversion

Dan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2011/2/25 Felipe Sateler :
> On Sun, Feb 20, 2011 at 20:59, Felipe Sateler  wrote:
>> On Sat, Feb 19, 2011 at 17:46, Dan S  wrote:
>>> 2010/10/31 Felipe Sateler :
>>>> Package: wnpp
>>>> Severity: wishlist
>>>> Owner: pkg-multimedia-maintain...@lists.alioth.debian.org
>>>>
>>>> * Package name    : supercollider
>>>>  Version         : 3.4
>>>>  Upstream Author : Lots of people
>>>> * URL             : http://supercollider.sourceforge.net
>>>> * License         : mostly GPL, some BSD, CC-BY-SA-3.0
>>>>  Programming Lang: C++
>>>>  Description     : A real time audio synthesis programming language
>>>>
>>>> SuperCollider is an environment and programming language for real time
>>>> audio synthesis and algorithmic composition. It provides an interpreted
>>>> object-oriented language which functions as a network client
>>>> to a state of the art, realtime sound synthesis server.
>>>
>>> OK, status of the supercollider packaging. Here's what I wrote on 4th
>>> jan (re a patch to add versioning to the soname):
>>>
>>>> The patch is in, upstream. What's happening right now is we're
>>>> preparing a 3.4.2 release, which will include this patch. (release
>>>> candidate files are at
>>>> <http://sourceforge.net/projects/supercollider/files/Source/3.4.2/>)
>>>>
>>>> The neatest thing is to wait for 3.4.2 official release, then import
>>>> it to the deb-mm repo and tweak the scripts for .so.1. Should be soon!
>>>
>>> Since then, there's been some delay in supercolliderland due to
>>> debating garbage-collection issues in the development branch. We can
>>> either wait more, or apply the patch downstream, in which case it
>>> would I think be ready for others to try? What's the next step once
>>> we're OK with the packaging?
>>
>> Since the patch is already applied upstream, and we are likely to wait
>> a while before 3.4.2 is out, it should be OK to apply the patch
>> locally to 3.4.1 for now. Please do that, and update the packaging
>> accordingly.
>
> Ping?

Pong, thanks, I will do this, busy I'm afraid - unlikely to happen
this weekend but it's on my list

Dan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602050: ITP: supercollider -- A real time audio synthesis programming language

[Dan S]

2010/10/31 Felipe Sateler :
> Package: wnpp
> Severity: wishlist
> Owner: pkg-multimedia-maintain...@lists.alioth.debian.org
>
> * Package name    : supercollider
>  Version         : 3.4
>  Upstream Author : Lots of people
> * URL             : http://supercollider.sourceforge.net
> * License         : mostly GPL, some BSD, CC-BY-SA-3.0
>  Programming Lang: C++
>  Description     : A real time audio synthesis programming language
>
> SuperCollider is an environment and programming language for real time
> audio synthesis and algorithmic composition. It provides an interpreted
> object-oriented language which functions as a network client
> to a state of the art, realtime sound synthesis server.

OK, status of the supercollider packaging. Here's what I wrote on 4th
jan (re a patch to add versioning to the soname):

> The patch is in, upstream. What's happening right now is we're
> preparing a 3.4.2 release, which will include this patch. (release
> candidate files are at
> )
>
> The neatest thing is to wait for 3.4.2 official release, then import
> it to the deb-mm repo and tweak the scripts for .so.1. Should be soon!

Since then, there's been some delay in supercolliderland due to
debating garbage-collection issues in the development branch. We can
either wait more, or apply the patch downstream, in which case it
would I think be ready for others to try? What's the next step once
we're OK with the packaging?

Dan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org