Re: Request for review & inclusion: supercollider-sc3-plugins (see RFP #807364)

[Hanno Zulla]

Am 05.01.2016 um 00:03 schrieb IOhannes m zmölnig (Debian/GNU):
> On 01/04/2016 02:32 PM, Hanno Zulla wrote:
>> - the packages are depending on (= ${binary:Version}) for each other
> 
> are you sure that "supercollider-sc3-plugins-sclang" must *Depend* on
> "supercollider-sc3-plugins-scsynth"?
> what if i want to run language and synth on different computers?
> i'd recommend using *Recommends*.

If this is an actual use-case, then Debian's supercollider packages do
not support it.



Right now, supercollider is set up that users can install the
synth-server without the language, but not the language without the
synth-server.

supercollider-language depends on supercollider-server.

As a result, since supercollider-sc3-plugins-sclang depends on
supercollider-language, this will pull in supercollider-server. And thus
you need supercollider-sc3-plugins-scsynth, too.

So yes, given Debian's current supercollider package,
supercollider-sc3-plugins-sclang must depend on
supercollider-sc3-plugins-scsynth.

What I'm not so sure about is wether supercollider-sc3-plugins-scsynth
should recommend or suggest supercollider-sc3-plugins-ladspalist. I used
"recommend" right now, but reading up on the FAQ, it seems to me that
"suggest" is the better choice, or is it not?

Thanks,

Hanno

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Request for review & inclusion: supercollider-sc3-plugins (see RFP #807364)

[Debian/GNU]

On 01/04/2016 02:32 PM, Hanno Zulla wrote:
> - the packages are depending on (= ${binary:Version}) for each other

are you sure that "supercollider-sc3-plugins-sclang" must *Depend* on
"supercollider-sc3-plugins-scsynth"?
what if i want to run language and synth on different computers?
i'd recommend using *Recommends*.

gfmsatd
IOhannes

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Request for review & inclusion: supercollider-sc3-plugins (see RFP #807364)

[Hanno Zulla]

Hi Sebastian,



fixed issues:

- the previously unresolvable build-dependency issue has been fixed by
  adding libjack-jackd2-dev

- ladspalist has been moved into its own, optional package

- ladspalist now has a man page

- the packages are depending on (= ${binary:Version}) for each other

- epoch has been removed from version number

I still don't know why "gbp clone" won't clone the pristine-tar branch
from github. If you know where my setup is wrong, please let me know.

In the meantime, you can use the "debian/rules get-orig-source" recipe
to have the tarball fetched from upstream & repacked.

Please review & give me a to-do list of items that need to be resolved.

Thanks,

Hanno


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Request for review & inclusion: supercollider-sc3-plugins (see RFP #807364)

[Sebastian Ramacher]

Hi

On 2015-12-21 17:05:16, Hanno Zulla wrote:
> > W: supercollider-sc3-plugins-scsynth: binary-without-manpage
> > usr/bin/ladspalist
> >
> > If the package is providing plugins to supercollider, should this
> > binary really be on $PATH?
> 
> As discussed on IRC, it's unclear to me where to place this binary.
> 
> LADSPA plugins can be used through one of the supercollider sc3 ugen
> plugins provided by this package.
> 
> The binary only lists those LADSPA plugins available to the user.
> 
> I'm not sure where else to put it but in /usr/bin. Packaging it in a
> separate .deb seems like overkill. Please advise.

Let me repeat my question from IRC: what is the purpose of this binary? Will a
user ever run this binary directly or is it only run by plugins?

What is the difference between ladspalist and listplugins from ladspa-sdk? If
ladspalist is a better version of listplugins, why is ladspalist contained in
supercollider-sc3-plugins instead of ladspa-sdk?

> > Do the three packages suppercollider-sc3-plugins,
> > supercollider-sc3-plugins-scsynth and
> > supercollider-sc3-plugins-sclang work in
> > any version combination should the dependencies by versioned?
> 
> They should be versioned. Do I have to mention the explicit version
> number in debian/control or is there a placeholder for it?

Check out ${source:Version} and ${binary:Version}.

> > Never use an epoch unless you really have to. And you don't have to,
> > since this was never in the Debian archive.
> 
> I have removed the epoch for now, but do want to put it in:
> 
> The package was in an Ubuntu PPA where a different versioning had been
> used so far and I would want to override that. Also, Debian's
> supercollider already uses an epoch and the sc3 plugins follow
> supercollider's version scheme.

Epochs can be used to fix mistakes in the versioning of a package or revert to
an older upstream version or to switch to another upstream with a completely
different versioning scheme. Nothing of that seems to apply here.

As long as the version is greater than the version used in the Ubuntu PPA, there
should not be a problem. And some Ubuntu PPA is really no good reason to
introduce an epoch. We'd have epochs everywhere …

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Request for review & inclusion: supercollider-sc3-plugins (see RFP #807364)

[Hanno Zulla]

Hi there,

> We have prepared a .deb package of supercollider-sc3-plugins at
> 
> and request review and, if acceptable, inclusion of the package.

After initial responses on IRC, I have tried to fix all issues discussed
there and (tada) started it anew, so the repository on github now
contains a fresh start.

Please review.

Thanks,

Hanno

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Request for review & inclusion: supercollider-sc3-plugins (see RFP #807364)

[Sebastian Ramacher]

On 2015-12-21 15:29:56, Hanno Zulla wrote:
> Hi there,
> 
> > We have prepared a .deb package of supercollider-sc3-plugins at
> > 
> > and request review and, if acceptable, inclusion of the package.
> 
> After initial responses on IRC, I have tried to fix all issues discussed
> there and (tada) started it anew, so the repository on github now
> contains a fresh start.

$ gbp buildpackage -uc -us -S
gbp:error: Pristine-tar couldn't checkout 
"supercollider-sc3-plugins_3.7.0~beta+git20151221.f978dc2~repack.orig.tar.xz": 
fatal: Path 
'supercollider-sc3-plugins_3.7.0~beta+git20151221.f978dc2~repack.orig.tar.xz.delta'
 does not exist in 'refs/heads/pristine-tar'
pristine-tar: git show 
refs/heads/pristine-tar:supercollider-sc3-plugins_3.7.0~beta+git20151221.f978dc2~repack.orig.tar.xz.delta
 failed

Never use an epoch unless you really have to. And you don't have to, since this
was never in the Debian archive.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Request for review & inclusion: supercollider-sc3-plugins (see RFP #807364)

[Hanno Zulla]

Hi there,

> Please build with dh $@ --parallel if possible.

fixed.

> I: supercollider-sc3-plugins source: duplicate-short-description
> supercollider-sc3-plugins supercollider-sc3-plugins-scsynth
> supercollider-sc3-plugins-sclang
> I: supercollider-sc3-plugins-scsynth:
> extended-description-is-probably-too-short

should be fixed.

> W: supercollider-sc3-plugins source: outdated-autotools-helper-file
> source/StkUGens/stk-4.4.4/config/
>
> This is from the embedded copy of stk.

upstream has removed stk as an embedded copy per request.

> This needs an update for the new location of nova-simd.

fixed & repacked. (Correctly repacked?)

> W: supercollider-sc3-plugins-scsynth: binary-without-manpage
> usr/bin/ladspalist
>
> If the package is providing plugins to supercollider, should this
> binary really be on $PATH?

As discussed on IRC, it's unclear to me where to place this binary.

LADSPA plugins can be used through one of the supercollider sc3 ugen
plugins provided by this package.

The binary only lists those LADSPA plugins available to the user.

I'm not sure where else to put it but in /usr/bin. Packaging it in a
separate .deb seems like overkill. Please advise.

man page will follow soon, no problem.

> I: supercollider-sc3-plugins-sclang: package-contains-empty-directory
> usr/share/SuperCollider/Extensions/SC3plugins/local/
>
> Is this empty directory needed?

no, removed.

> Do the three packages suppercollider-sc3-plugins,
> supercollider-sc3-plugins-scsynth and
> supercollider-sc3-plugins-sclang work in
> any version combination should the dependencies by versioned?

They should be versioned. Do I have to mention the explicit version
number in debian/control or is there a placeholder for it?

> If supercollider-sc3-plugins is just an empty metapackage, please put
> it in the correct section.

fixed.

> Why do you install upstream's TODO?

fixed, removed.

> gbp buildpackage -uc -us -S
> gbp:error: Pristine-tar couldn't checkout
"supercollider-sc3-plugins_3.7.0~beta+git20151221.f978dc2~repack.orig.tar.xz"

Please try again, I restarted the github repo once more.

If that still doesn't work, please advice me on what I did wrong there
and how to fix it.

In the meantime, you can use the
debian/rules get-orig-source
recipe to have the tarball fetched from upstream & repacked.

> Never use an epoch unless you really have to. And you don't have to,
> since this was never in the Debian archive.

I have removed the epoch for now, but do want to put it in:

The package was in an Ubuntu PPA where a different versioning had been
used so far and I would want to override that. Also, Debian's
supercollider already uses an epoch and the sc3 plugins follow
supercollider's version scheme.


Thanks so far,

Hanno

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Request for review & inclusion: supercollider-sc3-plugins (see RFP #807364)

[Sebastian Ramacher]

Hi Hanno

On 2015-12-15 10:51:03, Hanno Zulla wrote:
> 

It FTBFS with sbuild:

The following packages have unmet dependencies:
 sbuild-build-depends-supercollider-sc3-plugins-dummy : Depends: 
supercollider-dev (>= 3.6.6) but it is not going to be installed

Please build with dh $@ --parallel if possible.

lintian reports:

I: supercollider-sc3-plugins source: duplicate-short-description 
supercollider-sc3-plugins supercollider-sc3-plugins-scsynth 
supercollider-sc3-plugins-sclang
I: supercollider-sc3-plugins-scsynth: extended-description-is-probably-too-short

Should be easy to fix.

W: supercollider-sc3-plugins source: outdated-autotools-helper-file 
source/StkUGens/stk-4.4.4/config/config.guess 2004-02-26
W: supercollider-sc3-plugins source: outdated-autotools-helper-file 
source/StkUGens/stk-4.4.4/config/config.sub 2004-02-26

This is from the embedded copy of stk. Since it's not used, this warning should
be overridden.

I: supercollider-sc3-plugins source: wildcard-matches-nothing-in-dep5-copyright 
libs/nova-simd/* (paragraph at line 11)
I: supercollider-sc3-plugins source: unused-file-paragraph-in-dep5-copyright 
paragraph at line 11

This needs an update for the new location of nova-simd.

W: supercollider-sc3-plugins-scsynth: binary-without-manpage usr/bin/ladspalist

If the package is providing plugins to supercollider, should this binary really
be on $PATH?

I: supercollider-sc3-plugins-sclang: package-contains-empty-directory 
usr/share/SuperCollider/Extensions/SC3plugins/local/

Is this empty directory needed?

Do the three packages suppercollider-sc3-plugins,
supercollider-sc3-plugins-scsynth and supercollider-sc3-plugins-sclang work in
any version combination should the dependencies by versioned?

If supercollider-sc3-plugins is just an empty metapackage, please put it in the
correct section.

Why do you install upstream's TODO?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Request for review & inclusion: supercollider-sc3-plugins (see RFP #807364)

[Hanno Zulla]

Hi there,

Petter, Georges and I are preparing Sonic Pi (sonic-pi.net) for
Debian-compliant packaging, see RFP #796550


Sonic Pi combines an electronic synthesizer with a ruby interpreter to
create a new kind of electronic instrument. Made for school children
ages 8 and up, it teaches how to code through the joy of making music.

It comes pre-installed on Raspbian, but their .deb packaging rules are
unconvential.

Sonic Pi depends on supercollider as its synth backend and depends on
the supercollider sc3 plugin collection, see RFP #807364


We have prepared a .deb package of supercollider-sc3-plugins at



and request review and, if acceptable, inclusion of the package.

The package depends on libstk0-dev, but there was a packaging bug with
it that was fixed for sid with #805549 (thanks!). It would be beneficial
if the same libstk0-dev bug could be fixed for stretch, jessie and
wheezy to make the supercollider-sc3-plugins buildable there, see


Regards,

Hanno

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers