Re: request sponsor/upload for pd-pdstring
On Fri, Mar 2, 2012 at 10:28 AM, Roman Haefeli reduz...@gmail.com wrote: 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. Sorry for the (too long) delay. Uploaded -- Saludos, Felipe Sateler ___ 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
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
Re: request sponsor/upload for pd-pdstring
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: where is Pd's -stdlib? (was Re: request sponsor/upload for pd-pdstring)
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: where is Pd's -stdlib? (was Re: request sponsor/upload for pd-pdstring)
On Oct 4, 2011, at 5:19 AM, Roman Haefeli wrote: 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. if so, does this mean to be exclusive (e.g. only have the Pd install path) or inclusive (additionally have
Re: request sponsor/upload for pd-pdstring
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
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 09:19, Roman Haefeli wrote: This is probably not the right place to ask, but why is puredata packaged in a different team than all the pd-libraries? mainly because of legacy reasons. the current maintainer (paul), has not shown any inclination on moving the puredata package to pkg-multimedia. i think this should be respected. This is a bit of an unlucky situation. why? if the only reason is to not have to include paul's address in such discussions, then i think it is a rather lame excuse. (apart from that, it is mainly me who is responsible for the changes in question, and you do reach me via this group.) fmgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6JY74ACgkQkX2Xpv6ydvRPmgCdFIGsmRC8nepWrtj5nmxxUsbx bEMAnRuKVC42fKxaI1kKOGMkF64nqWFL =3U/R -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic 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 sponsor/upload for pd-pdstring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-01 14:11, Roman Haefeli wrote: On Fri, 2011-09-30 at 17:02 +0200, IOhannes m zmölnig wrote: 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. indeed, this is true (Pd's loader being more clever than i thought); sorry for the noise masdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6JZFQACgkQkX2Xpv6ydvRSLwCgyz0jzhxl0G6eBCg79anhOvX5 7OQAnjPTF7OAvCpNfSdG1uu9eaj6PFj8 =SAtJ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic 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
launchpad builders, was: request sponsor/upload for pd-pdstring
On Mo, Okt 03, 2011 at 08:56:00 (CEST), Roman Haefeli wrote: 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? No, launchpad builds in ubuntu chroots only. 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?) No, launchpad uses the same software as used on the debian buildds: sbuild (although it may be patched a bit differently) 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. TBH, I've found that sbuild/schroot (with aufs overlays) are a bit easier to setup than pbuilder-dist, but of course YMMV. Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
where is Pd's -stdlib? (was Re: request sponsor/upload for pd-pdstring)
-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) 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. if so, does this mean to be exclusive (e.g. only have the Pd install path) or inclusive (additionally have /usr/local/lib/pd-externals/ and ~/pd-externals/ (and on debian the additional /usr/lib/pd/extra/) i generally tend towards an inclusive solution, though i'm not 100% sure whether this is the user expectancy with regards to ~/pd-externals/ fgm,asdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6JajEACgkQkX2Xpv6ydvSVzgCgh78s7H3JNu5Ev/dhl3i2CxWj lPAAn2o/jopO8jnzi+Z6rRkUXxkCkO08 =rmN+ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic 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 sponsor/upload for pd-pdstring
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 11:50, Roman Haefeli wrote: 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. this is unreproducible for me: $ LANG=C aptitude show puredata | egrep '(Provides|Version)' Version: 0.43.0-4 Provides: pd $ LANG=C aptitude show puredata-core | egrep '(Provides|Version)' Version: 0.43.0-4 Provides: pd 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'? yes, that is why it does provide pd. Or is intended behavior that installing any pd-lib installs the full 'puredata' suite? definitely not. if so, the entire split of puredata into subpackages would have made no sense at all. 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 i think this is in accordance with the policy [1]. other people might have different opinions. fgmasdr IOhannes [1] http://www.debian.org/doc/debian-policy/ch-relationships.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6JiXMACgkQkX2Xpv6ydvSzxACg83+TKTtpFd8q8kLMfj8vdhAH u+gAoOiLIncv6cOnrSoXP3BKi/9Tz8U/ =enYo -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic 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 sponsor/upload for pd-pdstring
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
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
I find that Launchpad is a good place to test new packages. 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. .hc On Oct 1, 2011, at 8:11 AM, Roman Haefeli wrote: 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 I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ 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
On 11-10-02 at 12:16pm, Hans-Christoph Steiner wrote: I find that Launchpad is a good place to test new packages. 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. Below shouled work (written by memory, so might have missed some steps): # aptitude install sudo git-buildpackage cowbuilder # adduser myself sudo # cd /usr/local # git clone git://source.jones.dk/bin $ localcowbuilder-create sid $ cd my-package $ localgitcowdebuild sid --git-ignore-new $ git dch -a $ dch -r $ git commit -m Prepare for release: Update changelog. -a $ localgitcowdebuild sid --git-sign - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital 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 sponsor/upload for pd-pdstring
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
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2011 11:46 AM, Roman Haefeli wrote: If someone wants to have a look and eventually upload it? i cannot upload, but i can have a look: debian/control: current standards-version is 3.9.2 debian/control: Uploaders field has a stray trailing comma 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 know you care about ubuntu a lot, and i don't know the exact situation there) 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 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. also config.* and some other files seem to have different copyright holders 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 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 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 bringing this package to debian, mfasdft IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6FpuIACgkQkX2Xpv6ydvReqQCgzFEXrwLImHfR5GPHKxpohZd8 IfUAnA93Z7qv/wsuF+eqKgOW9ueunHYv =IFRa -END 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 sponsor/upload for pd-pdstring
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
-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. 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. debian/watch try something like: opts=uversionmangle=s/-/./ Thanks for the hint. With this I get: uscan warning: malformed opts=... in watchfile, skipping line: all arguments to uscan must be in the same line, so the you might want to add a \ for line-continueation to the opts line (which ought to go before the http://...) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6F2fUACgkQkX2Xpv6ydvT9sgCfXXDbGtrGPoGC7fhBXXSF7u2q vycAni8Rhu52p+FkZBSHfcwcAgVGQTtA =Zqia -END PGP SIGNATURE- #N canvas 3 44 650 163 24; #X declare -stdlib extra/pdstring -stdpath extra/pdstring; #X obj 21 37 declare -stdlib extra/pdstring -stdpath extra/pdstring ; #X obj 147 104 any2string; ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
