Re: request sponsor/upload for pd-pdstring

2012-03-02 Thread Roman Haefeli
Hi all

It's a while ago since the discussion about this package has stopped. To
my knowledge, there weren't any objections to uploading the package
left, however it has been done since. Is someone willing to have a look
again?

Many thanks in advance.

Roman


On Fri, 2011-09-30 at 11:46 +0200, Roman Haefeli wrote:
 Hi all
 
 I uploaded the pd-pdstring package to git.debian.org. It's a Pd library
 that eases the manipulation of strings in Pd by converting between Pd
 messages and lists of bytes.
 
 The package uses short-form dh.
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643837
 
 http://git.debian.org/?p=pkg-multimedia/pd-pdstring.git
 
 If someone wants to have a look and eventually upload it?
 
 Thanks
 Roman
 
 
 



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


Bug#661805: Classes [unpackOSCstream] and [packOSCstream] are broken

2012-03-01 Thread Roman Haefeli
Package: pd-osc
Version: 0.1-1
Severity: normal

The mentioned classes are broken due to the lack of the classes 
[slipenc] and [slipdec]. There is no package in Debian yet, that
provides those classes.

A suggested fix is to create a pd-slip package containing those
classes and make pd-osc depend on pd-slip.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pd-osc depends on:
ii  libc6   2.13-22
ii  puredata [pd]   0.43.1-1
ii  puredata-core [pd]  0.43.1-1

Versions of packages pd-osc recommends:
ii  pd-iemnet  0.1-2

Versions of packages pd-osc suggests:
pn  pd-comport  none

-- no debconf information



___
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 sponsor for / upload of pd-pdstring

2011-12-02 Thread Roman Haefeli
On Tue, 2011-11-29 at 20:00 -0300, Felipe Sateler wrote:
 On Fri, Nov 11, 2011 at 04:53, Roman Haefeli reduz...@gmail.com wrote:
 
  If time allows,
 
 Finally some time... :/
 
  could you also have a look at pd-pdstring? It's been
  waiting for some time and I have ironed out all issues that were
  discussed on this list.
 
 As discussed in another thread, the autotools stuff need not be
 documented in the copyright file, and is just unnecessary noise.

OK, I wait and adapt what is necessary as soon as there is some
consensus.
In this case, the autogenerated stuff is part of the source package, so
according to Jonas the licenses of those files need to be mentioned in
debian/copyright, if I understand correctly. 

 BTW, I still find it weird that we need to issue weird commands in pd
 to load distro-provided externals. Can someone please explain to me
 the rationale for such a requirement?

What is it that you do not understand? The mere fact that you need to
enable additional libraries in the patch or the weird way how this needs
to be done?

If the latter is the case, I don't have a real answer but that this is
the only way to _fully_ enable certain libraries. That is mainly because
Pd treats libraries consisting of abstractions (.pd files which are
themselves Pd patches) differently from externals (classes compiled from
C / C++ sources). If a certain library consists of both, you need the
weird line as mentioned in Readme.Debian.

Does that address your question?

Roman



___
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 sponsor for / upload of pd-flite

2011-11-10 Thread Roman Haefeli
On Thu, 2011-11-10 at 23:02 -0300, Felipe Sateler wrote:
 On Tue, Nov 8, 2011 at 19:16, Roman Haefeli reduz...@gmail.com wrote:
  On Mon, 2011-11-07 at 21:33 -0300, Felipe Sateler wrote:
  Please mark the package as ready for release by updating debian/changelog.
 
  Done so. It should be ready for upload now.
 
 Uploaded.

Thanks.

If time allows, could you also have a look at pd-pdstring? It's been
waiting for some time and I have ironed out all issues that were
discussed on this list.

Roman


___
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 sponsor for / upload of pd-flite

2011-11-08 Thread Roman Haefeli
On Mon, 2011-11-07 at 21:33 -0300, Felipe Sateler wrote:
 On Thu, Nov 3, 2011 at 17:51, Roman Haefeli reduz...@gmail.com wrote:

  I wasn't able to verify that but it certainly doesn't hurt. I replaced
  the spaces by dashes.
 
 config/missing still has spaces...

Oops. Thanks for spotting.

 The package looks OK (other than the above note).
 Please mark the package as ready for release by updating debian/changelog.

Done so. It should be ready for upload now.

Thanks
Roman




___
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 sponsor for / upload of pd-flite

2011-11-03 Thread Roman Haefeli
Hi Felipe

Thanks for your remarks.

On Wed, 2011-11-02 at 23:18 -0300, Felipe Sateler wrote:
 On Wed, Nov 2, 2011 at 12:52, Roman Haefeli reduz...@gmail.com wrote:
  I uploaded the pd-flite package to git.debian.org
 
 Some comments:
 
 The README.Debian should be signed by a real person IMO.

Changed.

 Please use the newer style git addresses (anonscm.debian.org)

Changed.

 I'm not a DEP5 expert but I think spaces are not allowed in the short
 descriptions of licenses.

I wasn't able to verify that but it certainly doesn't hurt. I replaced
the spaces by dashes.

 Also, I believe licenses should be either on a separate paragraph or
 written in the file paragraph but not both.

It's also more friendly for humans. Adjusted.

Roman


___
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 sponsor for / upload of pd-flite

2011-11-02 Thread Roman Haefeli
I uploaded the pd-flite package to git.debian.org. It contains a Pd
external for text-to-speech synthesis based on the flite implementation.

The package uses short-form dh.

It's quite a small package. I'd be very happy if someone could have a
look at it and eventually upload it.

Many thanks in advance.
Roman



___
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 sponsor/upload for pd-pdstring

2011-10-13 Thread Roman Haefeli
Hi again

It's been a few days, so forgive me if I bug you again.

The known issues have been fixed. Probably Pd people would like to have
a final look and confirm that the package in question is ready for
upload. I'd be happy if eventually a DD could upload it.

Thanks in advance.
Roman



On Mon, 2011-10-03 at 14:11 +0200, Roman Haefeli wrote:
 All the issue below have been fixed or do not belong to the package in
 question. 
 
 I'd be grateful if someone could have a look again and eventually upload
 it.
 
 Cheers
 Roman
 
 
 
 On Fri, 2011-09-30 at 16:19 +0200, Roman Haefeli wrote:
  Hi IOhannes
  
  First of all, thanks a lot for having such a thorough look.
  
  On Fri, 2011-09-30 at 13:24 +0200, IOhannes m zmölnig wrote:
  [...]
   debian/control:
current standards-version is 3.9.2
  
  fixed
  
   debian/control:
Uploaders field has a stray trailing comma
  
  oops... fixed.
  
   debian/control:
any reason why you are so picky about the debhelper version?
as jonas has pointed out before (e.g in the recent pd-zexy thread),
   debhelper-7 is even in oldstable, so you might happily use debhelper.
  
  I'm using short-form dh with dh overrides. Lintian tells me that those
  features are only available since 7.0.50. I read the thread about
  pd-zexy, but I _think_ the situation might be different there, because
  it is using cdbs (and thus probably not using dh overrides).
  
  http://lintian.debian.org/tags/debhelper-overrides-need-versioned-build-depends.html
  
   (i know you care about ubuntu a lot, and i don't know the exact
   situation there)
  
  I'm currently packaging on Debian/unstable and testing on both. I got
  the exact same lintian warnings/errors on both.
  
   debian/control:
Depends on pd,but there pd is only a virtual package, and you
   should provide a real one first.
   this is also caught by lintian:
   W: pd-pdstring: virtual-package-depends-without-real-package-depends
   depends: pd
   something like this should fix the problem:
   Depends: puredata-core | pd
  
  fixed.
  
   debian/copyright:
is it really true that moocow holds the copyright for files in debian/?
no file in debian/ has an explicit copyright notice (why), but i still
   doubt that moocow did the debian packaging.
  
  fixed
  
also config.* and some other files seem to have different copyright 
   holders
  
  Hopefully fixed. If someone could have look, that be nice, as this is
  the most tedious (I find) and probably rather error-prone part. 
  
  I was told on #debian-devel, that auto-generated files such as
  Makefile.in (generated by autotools) are not required to be listed in
  debian/copyright. So I left them out. Is that compliant with the
  practice of pkg-multimedia?
  
   debian/patches/add-meta-file.patch:
this patch is actually unneeded.
you could simply put the pdstring-meta.pd into debian/ and install it
   directly from there
btw, you could also use debian/install to install the file, rather than
   adding a dh_override
  
  Converted from patch to a simple debian/install command.
  
   debian/README.Debian
quite a long line :-)
more important, i cannot load pdstring following your advice in
   README.Debian: [declare -stdlib extra/pdstring] will do nothing (on
   reload), only [declare -lib pdstring] helps
  
  How did you test? The '-lib' flag searches relative to your patch,
  whereas '-stdlib' searches relative to pd. You only can correctly test
  it by effectively installing the package and run pd (/usr/bin/pd). 
  
  However, it turned out, that the advice was not complete, since the
  library also contains abstractions, which are not found with only
  '-stdlib extra/pdstring'. The full and correct declaration is:
  
  [declare -stdlib extra/pdstring -stdpath extra/pdstring]
  
  Yeah, that's a lot for loading only a library, but unfortunately that is
  how it currently works in Pd.
  
   debian/watch
it seems that the name is not mangled correctly, i get
   snip
   Newest version on remote site is 0.10-2, local version is 0.10.2
   pd-pdstring: remote site does not even have current version
   /snip
try something like:
opts=uversionmangle=s/-/./
  
  Thanks for the hint.
  With this I get: 
   uscan warning: malformed opts=... in watchfile, skipping line:
  
  I'll look later into that.
  
  Roman
  
  
  
 
 



___
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: RFS pd-zexy (was Re: pd-zexy review)

2011-10-10 Thread Roman Haefeli
On Mon, 2011-10-10 at 17:43 +0200, IOhannes m zmoelnig wrote:

 to my knowledge i have fixed all the remaining issues of the pd-zexy
 package.

Shouldn't pd-zexy depend only on puredata-core instead of puredata? Or
is there a particular reason that it wants full puredata?

Roman


___
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: RFS pd-zexy (was Re: pd-zexy review)

2011-10-10 Thread Roman Haefeli
On Mon, 2011-10-10 at 17:43 +0200, IOhannes m zmoelnig wrote:

 
 to my knowledge i have fixed all the remaining issues of the pd-zexy
 package.
 

The packages includes a lintian override statement:

snip
# the upstream library format includes the license file in it, this library
# has a unique license that is just a statement of public domain, so we just
# leave the file in place, since there is no license file to symlink to.
pd-zexy: extra-license-file usr/lib/pd/extra/zexy/LICENSE.txt
/snip

But the file usr/lib/pd/extra/zexy/LICENSE.txt seems to be (almost[1]) 
identical to GPL-2 from /usr/share/common-licenses

Either the included LICENSE.txt was meant to contain a different text or
the license actually is meant to be GPL-2 and thus should be symlinked
to /usr/share/common-licenses/GPL-2.

Roman


[1] It contains everything until the END OF TERMS AND CONDITIONS


___
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: where is Pd's -stdlib? (was Re: request sponsor/upload for pd-pdstring)

2011-10-04 Thread Roman Haefeli
On Mon, 2011-10-03 at 13:06 -0400, Hans-Christoph Steiner wrote:
 On Oct 3, 2011, at 3:54 AM, IOhannes m zmoelnig wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  @pd-dev: in the course of making packages for debian, we discovered
  another slight problem with the -stdpath and -stdlib flags for
  declare (and probably this also expands to the -nostdpath startup
  flag). following is an excerpt of the discussion in the debian  
  packaging
  team:
 
 
  On 2011-10-01 14:11, Roman Haefeli wrote:
 
  On Fri, 2011-09-30 at 17:02 +0200, IOhannes m zmölnig wrote:
 
  i'm not entirely sure though (given the nastiness of [declare])
  if you think that it is a bug in puredata-core, please file a  
  bugreport.
 
  Yeah, that is indeed the case. Before filing a bug report, I'd like  
  to
  clear up the meanings of the different paths.
 
  /usr/lib/pd/extra
   Am I right in assuming that this path is supposed to be searched by
   all flavors of Pd (all packages that provide the virtual package  
  pd)?
   This also the path where usually external libraries are installed to
   because from there they can be loaded from any flavor of pd?
 
  /usr/lib/puredata/extra
   is only searched by puredata / pd from the puredata package?
   This is where libraries are installed that only are suitable for
   the pd provided by the puredata package?
 
  /usr/lib/pd-extended/extra
   is only searched by pdextended / pd from the pd-extended package?
   Libs that are only useful with pdextended go there?
 
  If that is the case, then there is definitely a bug in the puredata- 
  core
  package as it is ignoring /usr/lib/pd/extra.
 
  it might as well be a bug in puredata upstream (that's why i want to
  discuss it; probably a more appropriate place for discussion is the
  pd-dev mailinglist which i include in the recipients)
 
  imho, the issue boils down to the question what are stdpaths? (and i
  assume that stdlibs are std because they live in stdpaths).
 
  for the sake of simplicity, i will only talk about the linux version
  of Pd (and with Pd i mean Pd-vanilla)
 
  before Pd-0.43 (vanilla!), there was only a single stdpath, which  
  was
  the path were the Pd binaries lived in. this usually was
  /usr/local/lib/pd/ or /usr/lib/pd/
 
  since 0.43, a few more paths have been added, namely:
  /usr/local/lib/pd-externals and ~/pd-externals
  on Debian and derivatives, yet another path is added: since Pd is
  installed into /usr/lib/puredata/ (in order to allow pd-extended live
  side by side with puredata), the path /usr/lib/pd is also added as a
  common system-managed search path.
 
  now all these paths are handled separately from the user defined
  search-paths; e.g. they do not show up in the path dialog, and they  
  can
  be disabled with the -nostdpaths flag.
 
  otoh, [declare] has not adapted to these changes.
  if you add -stdpath extra/foo, it will only search in
  /usr/local/lib/pd/extra/foo (given that pd is installed in
  /usr/local/lib/pd), but it will not search in
  /usr/local/lib/pd-externals/extra/foo nor in ~/pd-externals/extra/foo.
  (the same applies for the additional Debian-specific search path
  /usr/lib/pd/extra/foo).
  hence i do think that the problem is general problem with Pd-vanilla
  (and not specific to Debian; it only shows here)
 
 My guess is that [declare] should be adapted to consider as stdpath  
 the same stuff that -nostdpaths does.

I agree. I think that the various standard paths shouldn't be treated
differently. As a patch creator I don't care whether I installed the foo
library in ~/pd-externals or /usr/local/lib/pd/extra, in either case I
want to load a library the same way. 

I believe it makes sense to distinguish only two different scopes here:

* system environment
_all_ standard paths belong to it and the '-stdpath' and '-stdlib' 
flags of [declare] should expand all those paths, respectively try 
to load libraries from those paths.

* patch / local environment
paths relative to the patch's location. The '-lib' and '-path'
flags of [declare] cover those. 

I can't come up with another meaningful scope. But if there is any,
probably new flags for [declare] would be necessary.

  This also means, that currently all Pd libraries in unstable that
  install to /usr/lib/pd/extra (most of them do) are currently  
  broken, as
  there is no proper way to actually load them in pd (you still can
  specify the absolute path to the library, which renders your patch
  unportable to other OS').
 
  you could also simply start Pd with -lib foo and it will just work.
  so i wouldn't consider all broken.
  obviously, we lack the possibility to express a library dependency
  within the patch, which is a shame (but which is also due to the  
  current
  broken implementation of [declare] in general).
 
 
  anyhow, what i'm mainly asking is, whether std prefixed declare
  options and the std prefixed cmdline flags are supposed to work on  
  the
  same standard

Re: request sponsor/upload for pd-pdstring

2011-10-03 Thread Roman Haefeli
On Sun, 2011-10-02 at 12:16 -0400, Hans-Christoph Steiner wrote:
 I find that Launchpad is a good place to test new packages.  

Can you also use it to test against Debian releases? If yes, how?

 I think  
 you have a launchpad account already, so it should be easy.  I always  
 upload my packages to my launchpad before submitting them for upload  
 to Debian.  So far, I haven't remembered how to use cowbuilder or  
 pbuilder... an uploading to launchpad has stuck.

(Am I right in thinking that launchpad.net also uses pbuilder?)

Thanks for the tip. I'm actually using pbuilder-dist from the
ubuntu-dev-tools packages which is also available in Debian.
It's a wrapper around pbuilder that allows for easy deployments of
different Ubuntu and Debian distros. 

Roman



___
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 sponsor/upload for pd-pdstring

2011-10-03 Thread Roman Haefeli
On Sat, 2011-10-01 at 14:11 +0200, Roman Haefeli wrote:

 On Fri, 2011-09-30 at 17:02 +0200, IOhannes m zmölnig wrote:
 
  i'm not entirely sure though (given the nastiness of [declare])
  if you think that it is a bug in puredata-core, please file a bugreport.
 
 Yeah, that is indeed the case. Before filing a bug report, I'd like to
 clear up the meanings of the different paths.
 
 /usr/lib/pd/extra
   Am I right in assuming that this path is supposed to be searched by
   all flavors of Pd (all packages that provide the virtual package pd)?
   This also the path where usually external libraries are installed to 
   because from there they can be loaded from any flavor of pd?
 
 /usr/lib/puredata/extra
   is only searched by puredata / pd from the puredata package?
   This is where libraries are installed that only are suitable for
   the pd provided by the puredata package?
   
 /usr/lib/pd-extended/extra
   is only searched by pdextended / pd from the pd-extended package?
   Libs that are only useful with pdextended go there?
 
 If that is the case, then there is definitely a bug in the puredata-core
 package as it is ignoring /usr/lib/pd/extra.
 
 This also means, that currently all Pd libraries in unstable that
 install to /usr/lib/pd/extra (most of them do) are currently broken, as
 there is no proper way to actually load them in pd (you still can
 specify the absolute path to the library, which renders your patch
 unportable to other OS').

Let me refine this:

Since Pd-vanilla in Debian was moved to from /usr/lib/pd
to /usr/lib/puredata, some Debian-specific patches were necessary to
correct paths. There is also a patch that adds /usr/lib/pd to puredata's
search paths. This means that single-object libraries such as pd-wiimote
and pd-readanysf still work flawlessly, since if you instantiate
[wiimote] puredata will
find /usr/lib/pd/extra/wiimote/wiimote.pd_linux. 

The problem here is that [declare]'s '-stdpath' and '-stdlib' flags show
no effect for /usr/lib/pd/extra. Probably it got forgotten to make
[declare] not only expand the (new) native /usr/lib/puredata/extra path,
but also /usr/lib/pd/extra. This sound to me like a bug in the Debian
packaging.

On a sidenote: The fact that [declare -lib pdstring] loads the library
is contradictory to the [declare]'s documentation. The '-lib' flag
should only load libraries relative to the patch's path. But this is an
issue that is apparent also in upstream (probably since 0.41).

This is probably not the right place to ask, but why is puredata
packaged in a different team than all the pd-libraries? This is a bit of
an unlucky situation.

Roman




___
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 sponsor/upload for pd-pdstring

2011-10-03 Thread Roman Haefeli
On Fri, 2011-09-30 at 13:24 +0200, IOhannes m zmölnig wrote:

 debian/control:
  Depends on pd,but there pd is only a virtual package, and you
 should provide a real one first.
 this is also caught by lintian:
 W: pd-pdstring: virtual-package-depends-without-real-package-depends
 depends: pd
 something like this should fix the problem:
 Depends: puredata-core | pd

I followed the suggestion and lintian did not complain anymore. I
removed all the puredata/pd related packages from my unstable test
system and tried to install the resulting pd-pdstring package with gdebi
and got this:

$ sudo gdebi pbuilder/sid_result/pd-pdstring_0.10.2-1_amd64.deb 
Reading package lists... Done
Building dependency tree
Reading state information... Done
Building data structures... Done 
Building data structures... Done 
This package is uninstallable
Dependency is not satisfiable: pd

When I change the dependency for pd-pdstring to 'puredata | pd', it
installs fine by installing puredata.

I noticed that only the package 'puredata' provides the virtual package
'pd', but 'puredata-core' does not. 

So, what is the correct setup meant to be? Assuming that pd-libs are
running fine with only the core of Pd, shouldn't 'puredata-core' provide
'pd'?  Or is intended behavior that installing any pd-lib installs the
full 'puredata' suite?

Or asked more generally:
What is the common practice: depending on the least necessary or
depending on then most common setup (whatever that is)?

Roman


___
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 sponsor/upload for pd-pdstring

2011-10-03 Thread Roman Haefeli
On Mon, 2011-10-03 at 12:07 +0200, IOhannes m zmoelnig wrote
 On 2011-10-03 11:50, Roman Haefeli wrote:
  
  I noticed that only the package 'puredata' provides the virtual package
  'pd', but 'puredata-core' does not. 
 
 this is unreproducible for me:

Sorry for the noise. It is now for me as well :-/


  Or asked more generally:
  What is the common practice: depending on the least necessary or
  depending on then most common setup (whatever that is)?
 
 personally i have a quite strict opinion on this:
 Depend on the bare minimum
 Recommend the most common setup
 Suggest other possible use-cases

Totally makes sense to me. 

 [1] http://www.debian.org/doc/debian-policy/ch-relationships.html

Thanks for the link.

And sorry again for the noise. Can't even reproduce what I've done
(wrong) before.

Roman


___
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 sponsor/upload for pd-pdstring

2011-10-03 Thread Roman Haefeli
All the issue below have been fixed or do not belong to the package in
question. 

I'd be grateful if someone could have a look again and eventually upload
it.

Cheers
Roman



On Fri, 2011-09-30 at 16:19 +0200, Roman Haefeli wrote:
 Hi IOhannes
 
 First of all, thanks a lot for having such a thorough look.
 
 On Fri, 2011-09-30 at 13:24 +0200, IOhannes m zmölnig wrote:
 [...]
  debian/control:
   current standards-version is 3.9.2
 
 fixed
 
  debian/control:
   Uploaders field has a stray trailing comma
 
 oops... fixed.
 
  debian/control:
   any reason why you are so picky about the debhelper version?
   as jonas has pointed out before (e.g in the recent pd-zexy thread),
  debhelper-7 is even in oldstable, so you might happily use debhelper.
 
 I'm using short-form dh with dh overrides. Lintian tells me that those
 features are only available since 7.0.50. I read the thread about
 pd-zexy, but I _think_ the situation might be different there, because
 it is using cdbs (and thus probably not using dh overrides).
 
 http://lintian.debian.org/tags/debhelper-overrides-need-versioned-build-depends.html
 
  (i know you care about ubuntu a lot, and i don't know the exact
  situation there)
 
 I'm currently packaging on Debian/unstable and testing on both. I got
 the exact same lintian warnings/errors on both.
 
  debian/control:
   Depends on pd,but there pd is only a virtual package, and you
  should provide a real one first.
  this is also caught by lintian:
  W: pd-pdstring: virtual-package-depends-without-real-package-depends
  depends: pd
  something like this should fix the problem:
  Depends: puredata-core | pd
 
 fixed.
 
  debian/copyright:
   is it really true that moocow holds the copyright for files in debian/?
   no file in debian/ has an explicit copyright notice (why), but i still
  doubt that moocow did the debian packaging.
 
 fixed
 
   also config.* and some other files seem to have different copyright holders
 
 Hopefully fixed. If someone could have look, that be nice, as this is
 the most tedious (I find) and probably rather error-prone part. 
 
 I was told on #debian-devel, that auto-generated files such as
 Makefile.in (generated by autotools) are not required to be listed in
 debian/copyright. So I left them out. Is that compliant with the
 practice of pkg-multimedia?
 
  debian/patches/add-meta-file.patch:
   this patch is actually unneeded.
   you could simply put the pdstring-meta.pd into debian/ and install it
  directly from there
   btw, you could also use debian/install to install the file, rather than
  adding a dh_override
 
 Converted from patch to a simple debian/install command.
 
  debian/README.Debian
   quite a long line :-)
   more important, i cannot load pdstring following your advice in
  README.Debian: [declare -stdlib extra/pdstring] will do nothing (on
  reload), only [declare -lib pdstring] helps
 
 How did you test? The '-lib' flag searches relative to your patch,
 whereas '-stdlib' searches relative to pd. You only can correctly test
 it by effectively installing the package and run pd (/usr/bin/pd). 
 
 However, it turned out, that the advice was not complete, since the
 library also contains abstractions, which are not found with only
 '-stdlib extra/pdstring'. The full and correct declaration is:
 
 [declare -stdlib extra/pdstring -stdpath extra/pdstring]
 
 Yeah, that's a lot for loading only a library, but unfortunately that is
 how it currently works in Pd.
 
  debian/watch
   it seems that the name is not mangled correctly, i get
  snip
  Newest version on remote site is 0.10-2, local version is 0.10.2
  pd-pdstring: remote site does not even have current version
  /snip
   try something like:
   opts=uversionmangle=s/-/./
 
 Thanks for the hint.
 With this I get: 
  uscan warning: malformed opts=... in watchfile, skipping line:
 
 I'll look later into that.
 
 Roman
 
 
 



___
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 sponsor/upload for pd-pdstring

2011-10-01 Thread Roman Haefeli
Hi again

There was some confusion on my part, since I seem to have tested it only
in Debian stable where everything works as expected. The puredata
package in Debian unstable is quite different from previous versions and
also is its behavior.

On Fri, 2011-09-30 at 17:02 +0200, IOhannes m zmölnig wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 09/30/2011 04:19 PM, Roman Haefeli wrote:
  On Fri, 2011-09-30 at 13:24 +0200, IOhannes m zmölnig wrote:
  debian/control:
   any reason why you are so picky about the debhelper version?
  
  I'm using short-form dh with dh overrides. Lintian tells me that those
  features are only available since 7.0.50. I read the thread about
 
 thanks for the explanation.
 
  
  debian/README.Debian
   quite a long line :-)
   more important, i cannot load pdstring following your advice in
  README.Debian: [declare -stdlib extra/pdstring] will do nothing (on
  reload), only [declare -lib pdstring] helps
  
  How did you test? The '-lib' flag searches relative to your patch,
  whereas '-stdlib' searches relative to pd. You only can correctly test
  it by effectively installing the package and run pd (/usr/bin/pd).
 
 my test is to open the attached abstraction with
 $ puredata -noprefs pdstring-test.pd
 which gives me:
 snip
  any2string
 error: ... couldn't create
 /snip
 
 puredata (the 0.43.0-4) finds neither the library nor the abstraction of
 the name any2string.
 
 the former can be a bug in your documentation (i have to admit that i'm
 not so familiar with [declare]), as it would look for a library
 extra/pdstring where the pdstring.pd_linux file really is
 extra/pdstring/pdstring.pd_linux, so it should probably read -stdlib
 extra/pdstring/pdstring.

'-stdlib extra/pdstring/pdstring' is supposed to work as well but should
not be necessary at all. Pd normally checks also folders with the lib
name for libs. When specifying mylib, both extra/mylib.pd_linux and
extra/mylib/mylib.pd_linux are searched. 

  However, it turned out, that the advice was not complete, since the
  library also contains abstractions, which are not found with only
  '-stdlib extra/pdstring'. The full and correct declaration is:
  
  [declare -stdlib extra/pdstring -stdpath extra/pdstring]
  
  Yeah, that's a lot for loading only a library, but unfortunately that is
  how it currently works in Pd.
 
 after closer inspection it seems like this _might_ be a bug in the
 puredata package, which seems only to consider /usr/lib/puredata/ as
 a stdpath, and it won't search extra/pdstring in /usr/lib/pd.
 
 i'm not entirely sure though (given the nastiness of [declare])
 if you think that it is a bug in puredata-core, please file a bugreport.

Yeah, that is indeed the case. Before filing a bug report, I'd like to
clear up the meanings of the different paths.

/usr/lib/pd/extra
  Am I right in assuming that this path is supposed to be searched by
  all flavors of Pd (all packages that provide the virtual package pd)?
  This also the path where usually external libraries are installed to 
  because from there they can be loaded from any flavor of pd?

/usr/lib/puredata/extra
  is only searched by puredata / pd from the puredata package?
  This is where libraries are installed that only are suitable for
  the pd provided by the puredata package?
  
/usr/lib/pd-extended/extra
  is only searched by pdextended / pd from the pd-extended package?
  Libs that are only useful with pdextended go there?

If that is the case, then there is definitely a bug in the puredata-core
package as it is ignoring /usr/lib/pd/extra.

This also means, that currently all Pd libraries in unstable that
install to /usr/lib/pd/extra (most of them do) are currently broken, as
there is no proper way to actually load them in pd (you still can
specify the absolute path to the library, which renders your patch
unportable to other OS').

Roman






___
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 sponsor/upload for pd-pdstring

2011-09-30 Thread Roman Haefeli
Hi all

I uploaded the pd-pdstring package to git.debian.org. It's a Pd library
that eases the manipulation of strings in Pd by converting between Pd
messages and lists of bytes.

The package uses short-form dh.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643837

http://git.debian.org/?p=pkg-multimedia/pd-pdstring.git

If someone wants to have a look and eventually upload it?

Thanks
Roman




___
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 sponsor/upload for pd-pdstring

2011-09-30 Thread Roman Haefeli
Hi IOhannes

First of all, thanks a lot for having such a thorough look.

On Fri, 2011-09-30 at 13:24 +0200, IOhannes m zmölnig wrote:
[...]
 debian/control:
  current standards-version is 3.9.2

fixed

 debian/control:
  Uploaders field has a stray trailing comma

oops... fixed.

 debian/control:
  any reason why you are so picky about the debhelper version?
  as jonas has pointed out before (e.g in the recent pd-zexy thread),
 debhelper-7 is even in oldstable, so you might happily use debhelper.

I'm using short-form dh with dh overrides. Lintian tells me that those
features are only available since 7.0.50. I read the thread about
pd-zexy, but I _think_ the situation might be different there, because
it is using cdbs (and thus probably not using dh overrides).

http://lintian.debian.org/tags/debhelper-overrides-need-versioned-build-depends.html

 (i know you care about ubuntu a lot, and i don't know the exact
 situation there)

I'm currently packaging on Debian/unstable and testing on both. I got
the exact same lintian warnings/errors on both.

 debian/control:
  Depends on pd,but there pd is only a virtual package, and you
 should provide a real one first.
 this is also caught by lintian:
 W: pd-pdstring: virtual-package-depends-without-real-package-depends
 depends: pd
 something like this should fix the problem:
 Depends: puredata-core | pd

fixed.

 debian/copyright:
  is it really true that moocow holds the copyright for files in debian/?
  no file in debian/ has an explicit copyright notice (why), but i still
 doubt that moocow did the debian packaging.

fixed

  also config.* and some other files seem to have different copyright holders

Hopefully fixed. If someone could have look, that be nice, as this is
the most tedious (I find) and probably rather error-prone part. 

I was told on #debian-devel, that auto-generated files such as
Makefile.in (generated by autotools) are not required to be listed in
debian/copyright. So I left them out. Is that compliant with the
practice of pkg-multimedia?

 debian/patches/add-meta-file.patch:
  this patch is actually unneeded.
  you could simply put the pdstring-meta.pd into debian/ and install it
 directly from there
  btw, you could also use debian/install to install the file, rather than
 adding a dh_override

Converted from patch to a simple debian/install command.

 debian/README.Debian
  quite a long line :-)
  more important, i cannot load pdstring following your advice in
 README.Debian: [declare -stdlib extra/pdstring] will do nothing (on
 reload), only [declare -lib pdstring] helps

How did you test? The '-lib' flag searches relative to your patch,
whereas '-stdlib' searches relative to pd. You only can correctly test
it by effectively installing the package and run pd (/usr/bin/pd). 

However, it turned out, that the advice was not complete, since the
library also contains abstractions, which are not found with only
'-stdlib extra/pdstring'. The full and correct declaration is:

[declare -stdlib extra/pdstring -stdpath extra/pdstring]

Yeah, that's a lot for loading only a library, but unfortunately that is
how it currently works in Pd.

 debian/watch
  it seems that the name is not mangled correctly, i get
 snip
 Newest version on remote site is 0.10-2, local version is 0.10.2
 pd-pdstring: remote site does not even have current version
 /snip
  try something like:
  opts=uversionmangle=s/-/./

Thanks for the hint.
With this I get: 
 uscan warning: malformed opts=... in watchfile, skipping line:

I'll look later into that.

Roman




___
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: new package pd-readanysf

2011-01-18 Thread Roman Haefeli
Hi all

Now since gmerlin-avdecoder is in 'New', I think pd-readanysf is ready
for upload, too.

If anyone wants to have a look?

BTW: It uses short-form dh.

Roman



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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-08 Thread Roman Haefeli
On Sun, 2010-11-07 at 14:00 -0500, Hans-Christoph Steiner wrote:
 On Nov 5, 2010, at 7:01 PM, Roman Haefeli wrote:

  I'm interested to hear other opinions on this.

 pd-arraysize is a special case, not an example of how to do things.  
 There are plenty of simple packages in Debian, like simple kernel  
 modules for a very specific device.  In general packaging a single  
 simple object not a good idea, IMHO, but this one has a long legacy.
 arraysize has many uses, and is still widely used by people in their  
 patches, I use it regularly.

Now while thinking more about this, I realized why I never felt the need
for [arraysize] or any other measure to know the size of an array in the
the few years of using Pd: It's known already at any time. I can't think
of a situation where the size of an array is unknown. Actually, it is
always known, either because the table was provided a size argument or
the size was changed by loading a (sound-)file (an action that also
returns the new size, if '-resize' was used). To me this object is
basically useless. Checking the existing abstractions and help-files
using [arraysize] showed that [arraysize]  is only used in cases where
the patch author missed to keep track of the current size. I
acknowledge, though, that patching can be sometimes a lot easier with
[arraysize] under certain circumstances.

   It is also widely used in many Pd docs.   
 And many people prefer the simple syntax of typing arraysize vs  
 expr size($s1).

If you care about naming, then why don't you put [expr size($s1)] into
an abstraction called [arraysize]? I don't think [arraysize] is more
useful simply because it has a better name.

   Additionally, expr is GPL and arraysize is public  
 domain, so some people will use arraysize for that reason (i.e. a  
 proprietary app based on Pd like rjdj).

Good point.

I also checked how it is done in current releases of Pd-extended: There
[arraysize] was put into a folder called 'flatspace'. Would anything
speak against making a Debian package pd-flatspace out of all of those
externals and abstractions found in flatspace? To me it seems that this
folder is now used as a bin for an arbitrary and unrelated set of
externals and abstractions that are not part of another library or don't
fit well into another library. Why not keeping this structure also for
Debian packages? Then we would have a home for stuff like [arraysize].

Roman
 



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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-05 Thread Roman Haefeli
On Fri, 2010-11-05 at 00:10 +0100, IOhannes m zmoelnig wrote:
 On 2010-11-04 22:51, Felipe Sateler wrote:
 
  Usage in a helpfile does not really warrant a Depends relation.
  Recommends or Suggests are better.
 
 i couldn't have said this better.
 
 (esp. in this very case, where the help-patch is fully functional even
 without pd-pddp installed; having pd-pddp only allows to have a
 clickable link in the help-patch for more information, instead of a
 (harmless) error on the pd-console)

I'm not sure if I understand correctly: The proposed solution is to have
a missing object in help-file, unless the user does a manual install of
pd-pddp? So in future Debian releases, when people open help-files
they're welcomed with error messages?

Roman



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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-05 Thread Roman Haefeli
On Fri, 2010-11-05 at 10:11 +0100, Jonas Smedegaard wrote:
 On Fri, Nov 05, 2010 at 09:41:19AM +0100, Roman Haefeli wrote:
 On Fri, 2010-11-05 at 00:10 +0100, IOhannes m zmoelnig wrote:
  On 2010-11-04 22:51, Felipe Sateler wrote:
 
   Usage in a helpfile does not really warrant a Depends relation. 
   Recommends or Suggests are better.
 
  i couldn't have said this better.
 
  (esp. in this very case, where the help-patch is fully functional 
  even without pd-pddp installed; having pd-pddp only allows to have a 
  clickable link in the help-patch for more information, instead of a 
  (harmless) error on the pd-console)
 
 I'm not sure if I understand correctly: The proposed solution is to 
 have a missing object in help-file, unless the user does a manual 
 install of pd-pddp? So in future Debian releases, when people open 
 help-files they're welcomed with error messages?
 
 Almost:
 
 In the future when advanced users - who override recommendations - open 
 help-files they're welcomed with error messages.
 
 Recommends are for things useful for most users but not all, i.e. things 
 that does not cause the core functionality of the package to fail.
 
 In the past apt-get was broken and did not respect recommends and 
 instead treating them like suggests.  This lead to the myth that 
 recommends should be avoided.
 
 Please aggressively use recommends, for the benfit of unusual uses of 
 packages.

Thanks for making this clear for me. Recommends: pd-pddp sounds good
to me.

Roman


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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-05 Thread Roman Haefeli
On Fri, 2010-11-05 at 19:10 -0300, Felipe Sateler wrote:
 On Fri, Nov 5, 2010 at 00:51, Hans-Christoph Steiner h...@at.or.at wrote:

  As for packaging pd-arraysize together with other things, as far as I
  know, it is not Debian practice to lump together different upstream
  projects into a single package, I don't think its a good idea here
  either.
 
 
 It is perfectly acceptable, although not common. If there are more pd
 objects that are small, then just bundle them together.

I just happened to read on the pd-list, that [arraysize] is actually
obsolete, since this functionality is already built into both puredata
and pd-extended: [expr size($s1)]

Personally, I don't see a point in supporting double functionality. And
since this library doesn't do anything else, I'd actually prefer to
completely disregard it. I don't think that keeping it alive solely for
the sake of not breaking existing patches with future Debian version is
a good reason, especially since fixing those patches is so easy. In this
case I value tidiness of the pd-lib space more than backward
compatibility. Better not adding it in the first place than removing it
afterwards.

I'm interested to hear other opinions on this.

Roman
   


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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-04 Thread Roman Haefeli
On Thu, 2010-11-04 at 13:03 +, Luca Falavigna wrote:
 Hi,
 
 quoting from your debian/copyright:
 License: This code is too trivial to have a licence or copyright.
 
 Is it really necessary to distribute it in a standalone source package?

Yeah, I also think that this is questionable. I'm not the right person
to make decisions, but my opinion is that we (Pd people) should take the
chance now that we're pushing Pd libraries to Debian to try to make it
as clean as possible, i.e. try not to clutter the pd-lib space with too
many trivial single-object libraries. Since the code is so trivial that
it's not even worth being covered by a license, why not incorporating
into an existing library, hcs for instance? 

On an unrelated note: the help-file contains an object [pddp/pddplink],
but pd-array does not depend on a pd-pddp (which does not yet exist).
Personally, I think that the link in the help-file does not justify to
pull another dependency in, which is otherwise not necessary for
pd-arraysize to work properly at all. Unless we agree to make pddp a
standard within help-files, I'd propose to get rid of pddp links in
help-files of debianized Pd libraries.


Roman


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


Re: four more pd packages

2010-10-27 Thread Roman Haefeli
On Wed, 2010-10-27 at 00:57 -0400, Hans-Christoph Steiner wrote:
 On Sep 13, 2010, at 12:47 PM, Hans-Christoph Steiner wrote:
 
  On Mon, 2010-09-13 at 09:28 +0200, Alessio Treglia wrote:
  On Mon, Sep 13, 2010 at 12:14 AM, Hans-Christoph Steiner h...@at.or.at 
   wrote:
  pd-bassemu
  pd-earplug
  pd-freeverb
  pd-plugin
 
  pd-earplug
  pd-freeverb
  pd-plugin
 
  Please fix the following:
 
  - debian/copyright: The file doesn't match the spec proposal
  template. Take a look at one of the copyright files that I touched,
  they may help you.
  - debian/watch:
  version=3
  http://sf.net/pure-data/bassemu~-(.*)\.tar\.gz
 
  Replace `bassemu~` with the name of the component, it should be fine
  enough. To test it, run `uscan --dehs --report`
  - debian/control: I'd prefer to see applying a one-dep-per-line  
  style.
  - debian/gbp.conf: Add the field `sign-tags = True'
 
  Let me know when ready.
 
  Ok, I updated pd-earplug, pd-freeverb, and pd-plugin in  
  git.debian.org.
  Looks like you already did pd-bassemu.  I also applied these changes  
  to
  all the packages I've ITP'ed, which are currently in the pure-data  
  SVN,
  e.g.
  https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/loaders/libdir
 
  The packages that are still in pure-data SVN are waiting on the new
  puredata-dev, which is waiting in collab-maint/puredata.git for the
  Maintainer to comment on or upload.
 
  .hc
 
 
 Hey Alessio  Co,
 
 Any word on pd-earplug, pd-freeverb, and pd-plugin?  As far as I know,  
 they are all ready to be uploaded.
 timedia-maintainers

So are:
pd-wiimote
pd-iemnet

Roman


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


new package pd-readanysf

2010-10-06 Thread Roman Haefeli
Hi all

I uploaded a new package pd-readanysf, which is a Pd external object for
reading and receiving many audio formats.

ITP-Bug:  #598388

I'd be happy if someone could have a look.

Roman



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


Re: first package: pd-wiimote

2010-09-28 Thread Roman Haefeli
Hi all

Sorry to nag again.

@ Romain Beauxis
You said once I might ping you, since you might be interested to be
involved, since you also do the cwiid packages.

If noone has any further objections, it might be only a matter of
uploading it, I think.

Cheers
Roman


On Tue, 2010-09-14 at 19:49 +0200, Roman Haefeli wrote:
 Hi all
 
 I guess that all issues with the pd-wiimote package have been resolved.
 Do you think it can be uploaded?
 
 Many thanks
 Roman
 
 



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


Re: first package: pd-wiimote

2010-09-14 Thread Roman Haefeli
Hi all

I guess that all issues with the pd-wiimote package have been resolved.
Do you think it can be uploaded?

Many thanks
Roman



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


Re: [SCM] pd-wiimote/master: added 'pd' as Depends: and formatted one-dep-per-line

2010-09-13 Thread Roman Haefeli
On Mon, 2010-09-13 at 18:05 +,
eighthave-gu...@users.alioth.debian.org wrote:
 The following commit has been merged in the master branch:
 commit b8e8dcd45d28ecd349def4d2eb85e443f85980d8
 Author: Hans-Christoph Steiner h...@eds.org
 Date:   Mon Sep 13 14:05:07 2010 -0400
 
 added 'pd' as Depends: and formatted one-dep-per-line
 

Oops, thanks for adding it. 

BTW: Is it now a standard that pd-libs should depend on the meta package
'pd' instead of 'puredata'?

Roman



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


Re: first package: pd-wiimote

2010-09-03 Thread Roman Haefeli
On Thu, 2010-09-02 at 17:22 +0200, Roman Haefeli wrote:
 On Thu, 2010-09-02 at 11:13 -0400, Felipe Sateler wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
  
  On 02/09/10 05:10, Reinhard Tartler wrote:
  
So another approach would be to repackage the
   tarball to just include the COPYING file. While we are at it, we could
   also use the new Makefile and get rid of the other patch.
  
   Instead of using a quilt patch should I simply replace the Makefile with
   the new one and check that into the master branch?
   
   no, that would be pretty confusing. I'd rather do these changes in the
   'upstream' branch branch, and have a wiimote-0.3.1.dfsg1.orig.tar.gz
   created or something.
   
  
  The correct approach is to have upstream fix this, not us. In the
  current workflow, touching the upstream branch for stuff other than
  merging upstream versions is wrong IMO.
  
 
 Ok. It's in progress. I'll report back, when done.

First off, many thanks to you all for your help.

IOhannes helped me putting up a new upstream version 0.3.2, which has
now a fixed Makefile and also a license file. So I could remove the
quilt patch wierdness.

I hope it looks OK now.

Ah, one thing: Since it wasn't put to the archive yet, I didn't add a
new changelog entry, but updated the existing one. Is this the correct
way?

Roman
 


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


Re: first package: pd-wiimote

2010-09-03 Thread Roman Haefeli
On Fri, 2010-09-03 at 18:29 +0200, Jonas Smedegaard wrote:
 On Fri, Sep 03, 2010 at 05:43:32PM +0200, Roman Haefeli wrote:
 On Thu, 2010-09-02 at 17:22 +0200, Roman Haefeli wrote:
  On Thu, 2010-09-02 at 11:13 -0400, Felipe Sateler wrote:
   On 02/09/10 05:10, Reinhard Tartler wrote:
  
So another approach would be to repackage the tarball to just 
include the COPYING file. While we are at it, we could also use 
the new Makefile and get rid of the other patch.
   
Instead of using a quilt patch should I simply replace the 
Makefile with the new one and check that into the master branch?
   
no, that would be pretty confusing. I'd rather do these changes 
in the 'upstream' branch branch, and have a 
wiimote-0.3.1.dfsg1.orig.tar.gz created or something.
   
  
   The correct approach is to have upstream fix this, not us. In the 
   current workflow, touching the upstream branch for stuff other than 
   merging upstream versions is wrong IMO.
  
 
  Ok. It's in progress. I'll report back, when done.
 
 First off, many thanks to you all for your help.
 
 IOhannes helped me putting up a new upstream version 0.3.2, which has 
 now a fixed Makefile and also a license file. So I could remove the 
 quilt patch wierdness.
 
 I hope it looks OK now.
 
 I noticed you switched to source version 3.0 from quilt to native.  I 
 would suggest to keep using the quilt flavor even if not currently 
 needing any patches: if at some point upstream code is changed - 
 accidentally or deliberately - we want it to be treated by packaging 
 routines as a patch, not a change by upstream.

Sounds reasonable. Done.

Roman


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


Re: first package: pd-wiimote

2010-09-02 Thread Roman Haefeli
On Thu, 2010-09-02 at 01:07 -0400, Hans-Christoph Steiner wrote:
 Looks pretty good to me, but I'm just learning myself :)

Thanks for having a look.
One thing I like to mention: The upstream sources come with a Makefile
based on a apparently old Makefile template for libdirs. It was pretty
broken and created superfluous directories in debian/. I copied over the
current template, adapted it and applied it as a quilt patch. Is that
the proper way to do it?

   I am  
 wondering about the strip stuff:

 override_dh_strip:
   strip --remove-section=.comment --remove-section=.note --strip- 
 unneeded \
   debian/pd-wiimote/usr/lib/pd/extra/wiimote/wiimote.pd_linux
 
 My guess is that this is needed in order to properly strip  
 the .pd_linux so binaries?
 

Yeah, dh_strip apparently does not consider .pd_linux files as shared
objects and also there is no way to force it by passing it file names as
arguments. 

I used the strip command from a mail by Felipe Sateler [1]

[1]
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/012336.html

Roman


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


Re: first package: pd-wiimote

2010-09-02 Thread Roman Haefeli
On Thu, 2010-09-02 at 09:38 +0200, Reinhard Tartler wrote:
 On Thu, Sep 02, 2010 at 01:16:03 (CEST), Roman Haefeli wrote:
 
  Hi all
 
  I checked in my first package. I tried to follow - where possible - very
  closely to pd-motex, which has been already uploaded.
  I would be glad if someone could have a look at it.
 
  FYI: It is using what I believe is called short-form dh.
 
 indeed, it is.
 
 I've taken a quick look at the package,
  it's a really small package and
 rather easy to review.
 
 Packagingwise, I think it is fine, but I'm umcomfortable with the two
 patches. First, please use the patch metadata as described in
 http://dep.debian.net/deps/dep3/.
 
 But as for the actual patches, I'm rather uncomfortable with
 them. The add-license patch adds the complete text of the GPL. I'm not
 sure how the ftpteam thinks about it, but to me it feels very
 strange. Is upstream aware of the problem, can't they just reissue the
 tarball with the complete license text? Moreover, quoting the part How
 to Apply These Term to Your New Programs is usually also helpful.
 
 I'd be more comfortable if the GPL text was just included in debian/,
 read, as non-patch, but still, I really think this file should be part
 of the orig.tar.gz.

The reason why I added the LICENSE file in the first place is because
the Makefile is hardcoded to install it. Probably I shouldn't have done
it as a patch. But then again in the thread about pd-motex people agreed
that it would be better to create a symlink to the respective license
in /usr/share/common-licenses/.
So actually, I could remove install LICENSE line in the Makefile which
makes the add-license.patch obsolete  and let debian/rules do the
symlink and the result will be the same. What do you think?

  So another approach would be to repackage the
 tarball to just include the COPYING file. While we are at it, we could
 also use the new Makefile and get rid of the other patch.

Instead of using a quilt patch should I simply replace the Makefile with
the new one and check that into the master branch?

Roman



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


Re: first package: pd-wiimote

2010-09-02 Thread Roman Haefeli
On Thu, 2010-09-02 at 10:48 +0200, Jonas Smedegaard wrote:
 On Thu, Sep 02, 2010 at 09:38:56AM +0200, Reinhard Tartler wrote:
 Packagingwise, I think it is fine, but I'm umcomfortable with the two 
 patches. First, please use the patch metadata as described in 
 http://dep.debian.net/deps/dep3/.
 
 Oh, only saw this _after_ sending off same suggestion myself.  Sorry for 
 the noice :-)
 
 
 But as for the actual patches, I'm rather uncomfortable with
 them. The add-license patch adds the complete text of the GPL. I'm not
 sure how the ftpteam thinks about it, but to me it feels very
 strange. Is upstream aware of the problem, can't they just reissue the
 tarball with the complete license text? Moreover, quoting the part How
 to Apply These Term to Your New Programs is usually also helpful.
 
 I'd be more comfortable if the GPL text was just included in debian/,
 read, as non-patch, but still, I really think this file should be part
 of the orig.tar.gz. So another approach would be to repackage the
 tarball to just include the COPYING file. While we are at it, we could
 also use the new Makefile and get rid of the other patch.
 
 I really don't get the logic of _adding_ a license at all.
 
 I know that GPL boilerplate mentions that you are supposed to receive a 
 COPYING file together with source, but I do not see it being _mandatory_ 
 so if upstream fails to do it I suppose we are allowed to redistribute 
 verbatim - i.e. also lacking same file.
 
 If it is not for licensing reasons but due to being meeded by the code 
 at runtime, then I suggest copying/symlinking the file below 
 /usr/share/common-licenses instead.

It is actually not needed for running the program, but the libdir format
for Pd libraries proposed by Hans-Christoph Steiner defines a
LICENSE.txt and README.txt to be included in every Pd library. 

Currently, the quilt patch adds the license which is later replaced by a
symlink (see debian/links). I think I remove the patch and simply leave
the symlink.

Roman


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


Re: first package: pd-wiimote

2010-09-02 Thread Roman Haefeli
On Thu, 2010-09-02 at 11:13 -0400, Felipe Sateler wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 02/09/10 05:10, Reinhard Tartler wrote:
 
   So another approach would be to repackage the
  tarball to just include the COPYING file. While we are at it, we could
  also use the new Makefile and get rid of the other patch.
 
  Instead of using a quilt patch should I simply replace the Makefile with
  the new one and check that into the master branch?
  
  no, that would be pretty confusing. I'd rather do these changes in the
  'upstream' branch branch, and have a wiimote-0.3.1.dfsg1.orig.tar.gz
  created or something.
  
 
 The correct approach is to have upstream fix this, not us. In the
 current workflow, touching the upstream branch for stuff other than
 merging upstream versions is wrong IMO.
 

Ok. It's in progress. I'll report back, when done.

Thanks for your help
Roman


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


first package: pd-wiimote

2010-09-01 Thread Roman Haefeli
Hi all

I checked in my first package. I tried to follow - where possible - very
closely to pd-motex, which has been already uploaded.
I would be glad if someone could have a look at it.

FYI: It is using what I believe is called short-form dh.

Cheers
Roman




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


Re: pd-zexy compilation improvements

2010-08-29 Thread Roman Haefeli
On Sun, 2010-08-29 at 14:44 -0400, Hans-Christoph Steiner wrote:

  
  Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
  figured out what trickery was used in the gem package to let it find
  also .pd_linux-files. But having a plain .pd-linux file in the temporary
  directory and running dh_shlibdeps doesn't produce anything useful.
 
 You can also check out debian/rules in pd-motex and pd-pmpd.  It passes
 the names of the .pd_linux files to dh_shlibdeps.


Actually, you're not passing the file names to dh_shlibdeps, but
directly to dpkg-shlibdeps. 
According to 4.4.3 of Debian's new maintainer's guide [1] the
recommended way would be to pass customized arguments to the debhelper
tools after  -- , so that they get passed to the respective dpkg tools
(or whatever the dh_tool is a wrapper for).
 
However, this does not seem to work here for some reason.

$ dpkg-shlibdeps some/file.pd_linux 

actually creates a reasonable debian/substvars file.

$ dh_shlibdeps -- some/file.pd_linux

which is supposed to do exactly the same (according to the
documentation) does not seem to find a file to check for libraries. 

So, I guess dh_shlibdeps --  is not passing _all_ arguments to
dpkg-shlibdeps? My perl skills are too limited to investigate the reason
for this behaviour myself. 

Since the recommended way is not working, I guess it is OK to call
dpkg-shlibdeps directly in the pd-packages (as you, Hans, did in
pd-motex and pd-pmpd)? Or what do you (all) think?

Roman



[1] http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-customrules


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


Re: pd-zexy compilation improvements

2010-08-28 Thread Roman Haefeli
On Fri, 2010-08-27 at 19:24 -0400, Felipe Sateler wrote:
 On 27/08/10 18:18, Roman Haefeli wrote:
  On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote:
  On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:
  On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:
 
  Hmm. Do we then perhaps need to beware of this for helper tools like
  lintian and dh_shlibdeps?
 
  
  the other point is of course, whether tools like dh_shlibdeps and
  dh_strip work correctly.
  i can only say from experience, that they do.
  e.g. the binary Gem.pd_linux in the package gem is correctly stripped
  and the package depends on all packages that provide libraries the
  binary has been dynamically linked to.
  debian/rules does not extra care of shlibs.
  so it seems to just work
  
  It seems it's not dh_strip who does the stripping. In the case of the
  gem package it seems to happen already at compile time. After putting an
  unstripped Gem.pd_linux in the temporary directory running dh_strip
  won't touch it all. 
 
 dh_strip doesn't strip anything it doesn't recognize (and it has no way
 of being forced into it). Add comments to bug #468333 to ask for support
 for this.

Thanks for confirming.

 In the meantime, you can call
 
 strip --remove-section=.comment --remove-section=.note --strip-unneeded

 on each of the pd_linux files.

Ok.

  Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
  figured out what trickery was used in the gem package to let it find
  also .pd_linux-files. But having a plain .pd-linux file in the temporary
  directory and running dh_shlibdeps doesn't produce anything useful.
 
 You can pass additional arguments for dh_shlibdeps to process:
 
 dh_shlibdeps -- $file1 $file2

Ah, so easy. Thanks for the hint.

Roman


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


Re: request for membership, ITA

2010-08-28 Thread Roman Haefeli
On Fri, 2010-08-27 at 19:11 -0400, Felipe Sateler wrote:
 On 26/08/10 14:39, Roman Haefeli wrote:
  On Wed, 2010-08-25 at 14:22 +0200, Jonas Smedegaard wrote:
  
  When that's done, you have write access to our Git area at Alioth: then 
  please upload your packaging there and let us[1] look at it together.
  
  Thanks for your help. Am I supposed to have already access to
  git.debian.org/git/pkg-multimedia?
  
  I think I don't. My username on alioth is rdz-guest. 
  
 
 Now you do. Welcome to the team!

Cool! Thank you!
Roman


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


Re: request for membership, ITA

2010-08-27 Thread Roman Haefeli
On Wed, 2010-08-25 at 14:22 +0200, Jonas Smedegaard wrote:

 
 Please read http://wiki.debian.org/DebianMultimedia - and especially 
 http://wiki.debian.org/DebianMultimedia/Join :-)
 
 When that's done, you have write access to our Git area at Alioth: then 
 please upload your packaging there and let us[1] look at it together.

I forgot to mention that my username on alioth is:
rdz-guest

Roman



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


Re: request for membership, ITA

2010-08-27 Thread Roman Haefeli
On Wed, 2010-08-25 at 14:22 +0200, Jonas Smedegaard wrote:

 When that's done, you have write access to our Git area at Alioth: then 
 please upload your packaging there and let us[1] look at it together.

Thanks for your help. Am I supposed to have already access to
git.debian.org/git/pkg-multimedia?

I think I don't. My username on alioth is rdz-guest. 

Thanks
Roman


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


Re: request for membership, ITA

2010-08-27 Thread Roman Haefeli
Hi Hans

Thanks for your support so far.

On Wed, 2010-08-25 at 11:52 -0400, Hans-Christoph Steiner wrote:

 A couple minor details on your ITP bug report:
 
 - in the description, I've been using Pd then using Pure Data in  
 the long description so both are findable via search. Since its  
 written text, I think we can use the more common written forms of Pd  
 and Pure Data rather than the package name of puredata

Yeah, makes sense. 

 - also, I've been using the word objects instead of externals  
 since I think its clearer to more people, especially Pd newbies.

I'm not so sure about that. Personally, I find objects confusing for
describing shared library files, since it seems to be more often used to
describe instantiations of object classes, at least on Pd mailing list
and on #dataflow. I still think that external fits very well for
external libraries (which is what they are). Also with naming I am more
concerned about consistency than with newbie friendliness (hoping that
the former will be the base of the latter).

OTOH, pd-zexy which is included for a long while now also talks about
objects. So I happily adopt your suggestion, since it somehow seems
already established. (OTOH, pd-motex talks about externals again)

hm..

Roman

 On Aug 25, 2010, at 7:30 AM, Roman Haefeli wrote:
 
  Hi all
 
  Following IOhannes m zmoelnig and Hans-Christoph Steiner (both
  subscribed to this list and both now members of the pkg-mutlimedia  
  team)
  I would like to join the forces to bring some Pure Data related  
  packages
  into Debian and to help with the maintenance of those. I hope to do  
  this
  in favour of both the Debian community and the Pd community.
 
  I've been involved in the Pd community for a few years and use the
  software and its externals on a regular basis. I don't have written
  externals myself, since I am no C developer, but I contributed code in
  form of so called abstractions (modules written in the Pd language).
 
  I closely followed the process of finalizing the pd-motex package to
  make it Debian ready and now that it was finally uploaded, I'd like to
  try it myself with the package pd-wiimote.
 
  I posted a ITA bug report: Bug#593411
  I am currently hosting it at:
  http://github.com/reduzent/pd-wiimote
 
  Many thanks for addressing this request in advance.
 
  Roman
 
 
 
 
  ___
  pkg-multimedia-maintainers mailing list
  pkg-multimedia-maintainers@lists.alioth.debian.org
  http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
 
 
 
 
 
 [W]e have invented the technology to eliminate scarcity, but we are  
 deliberately throwing it away to benefit those who profit from  
 scarcity.-John Gilmore
 
 



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


Re: request for membership, ITA

2010-08-27 Thread Roman Haefeli
Hi Romain

On Wed, 2010-08-25 at 10:32 -0500, Romain Beauxis wrote:
 I have always wanted to look at PD more closely

I think it is definitely worth it. I'll be glad to help, if you need it.

 and I also packaged cwiid, 
 which I suspect is a dependency of this package.

Indeed, it is.

 Therefore, it seems I am a good candidate to look at this :-)

So I am very glad that I met you ;-)

 I will try to do it soon, ping me if no one else did it before and I did not 
 send any follow-up..

No hurry. For my part, I am very happy to join the team and to
collaborate, but forgive me if I sometimes answer mails not immediately
(as my free time is sometimes a bit fragmented) 

Roman


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


Re: pd-zexy compilation improvements

2010-08-27 Thread Roman Haefeli
On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote:
 On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:
  On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:
 
  Hmm. Do we then perhaps need to beware of this for helper tools like
  lintian and dh_shlibdeps?
  

 the other point is of course, whether tools like dh_shlibdeps and
 dh_strip work correctly.
 i can only say from experience, that they do.
 e.g. the binary Gem.pd_linux in the package gem is correctly stripped
 and the package depends on all packages that provide libraries the
 binary has been dynamically linked to.
 debian/rules does not extra care of shlibs.
 so it seems to just work

It seems it's not dh_strip who does the stripping. In the case of the
gem package it seems to happen already at compile time. After putting an
unstripped Gem.pd_linux in the temporary directory running dh_strip
won't touch it all. 

Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
figured out what trickery was used in the gem package to let it find
also .pd_linux-files. But having a plain .pd-linux file in the temporary
directory and running dh_shlibdeps doesn't produce anything useful.

Roman


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


request for membership, ITA

2010-08-25 Thread Roman Haefeli
Hi all

Following IOhannes m zmoelnig and Hans-Christoph Steiner (both
subscribed to this list and both now members of the pkg-mutlimedia team)
I would like to join the forces to bring some Pure Data related packages
into Debian and to help with the maintenance of those. I hope to do this
in favour of both the Debian community and the Pd community. 

I've been involved in the Pd community for a few years and use the
software and its externals on a regular basis. I don't have written
externals myself, since I am no C developer, but I contributed code in
form of so called abstractions (modules written in the Pd language). 

I closely followed the process of finalizing the pd-motex package to
make it Debian ready and now that it was finally uploaded, I'd like to
try it myself with the package pd-wiimote. 

I posted a ITA bug report: Bug#593411
I am currently hosting it at:
http://github.com/reduzent/pd-wiimote

Many thanks for addressing this request in advance. 

Roman




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