Bug#603175: pd-osc (was Re: Bug#603175: reorganize upstream first)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi martin, in the process of getting numerous pd-libraries into debian (and thus ubuntu and other debian derivatives), we stumbled upon a small issue in your set of objects. as things are right now, there are no "upstream releases" of your libraries; in SVN they are organized (as you are well aware) into a mrpeach/ folder with various task-specific sub-folders. historically, Pd-extended used the mrpeach/ folder as an organizational unit. (install everything you created into a flat extra/mrpeach/ folder) however, since your libraries don't have anything in common apart from you as the author, i would prefer to package them into separate packages, according to the tasks they are associated with (at least those where there i a notion of 'library' as is the case with your net-, osc-, cmos- objects, so people can install "pd-osc" if they need OSC communication (and don't need your net/ implementation, as they intend to send OSC over serial/slip). the rough idea is to have packages for - - OSC - - net - - cmos - - midifile - - binfile - - slip - - str - - oscillators - - tabletools - - which the debian packages would be named accordingly, with "pd-" prepended (or "pd-mrpeach-" for generic names like "tabletools" and "oscillators", in order to distinguish them from other libraries that could claim those generic names with equal rights) eventually i'm planning to have a "pd-mrpeach" meta-package that would depend on all these sub-packages and provide a compatibility layer for older (pd-extended) patches. nothing is required from you to actually _do_ (e.g. code-wise), but as hans has correctly pointed out, it would be good to know your feelings about all this. cheers fgamsdr IOhannes On 2011-06-13 17:26, Hans-Christoph Steiner wrote: > > Tags: upstream > > Since there is no distinct pd-osc upstream, there are no separate > releases from the upstream author only svn, and the only circulating > release is the is the 'mrpeach' library included in Pd-extended, I think > we need to first get this stuff organized upstream before uploading a > package to Debian. Have you talked with Martin Peach about it? I think > it makes sense to have pd-osc, but I think the upstream author should > determine how the code is released. The 'mrpeach' thing could be > dropped, for example, if Martin wants it that way. > > .hc > > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk33ZAEACgkQkX2Xpv6ydvSN8ACeOL5AKdtccX+xl5Q0xrkoGHnt QmAAnR1TlHVcbqkaf3DqFdXL2Qsvpm7r =Wwm4 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Bug#603175: pd-osc (was Re: Bug#603175: reorganize upstream first)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I also think that having it separate libraries like 'osc' and 'net' makes sense, then we can phase out the 'mrpeach' lib or whatever. Mostly, its your code, so it'd be good to hear how you want to have it released and packaged. .hc On Jun 14, 2011, at 9:37 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi martin, in the process of getting numerous pd-libraries into debian (and thus ubuntu and other debian derivatives), we stumbled upon a small issue in your set of objects. as things are right now, there are no "upstream releases" of your libraries; in SVN they are organized (as you are well aware) into a mrpeach/ folder with various task-specific sub-folders. historically, Pd-extended used the mrpeach/ folder as an organizational unit. (install everything you created into a flat extra/mrpeach/ folder) however, since your libraries don't have anything in common apart from you as the author, i would prefer to package them into separate packages, according to the tasks they are associated with (at least those where there i a notion of 'library' as is the case with your net-, osc-, cmos- objects, so people can install "pd-osc" if they need OSC communication (and don't need your net/ implementation, as they intend to send OSC over serial/slip). the rough idea is to have packages for - - OSC - - net - - cmos - - midifile - - binfile - - slip - - str - - oscillators - - tabletools - - which the debian packages would be named accordingly, with "pd-" prepended (or "pd-mrpeach-" for generic names like "tabletools" and "oscillators", in order to distinguish them from other libraries that could claim those generic names with equal rights) eventually i'm planning to have a "pd-mrpeach" meta-package that would depend on all these sub-packages and provide a compatibility layer for older (pd-extended) patches. nothing is required from you to actually _do_ (e.g. code-wise), but as hans has correctly pointed out, it would be good to know your feelings about all this. cheers fgamsdr IOhannes On 2011-06-13 17:26, Hans-Christoph Steiner wrote: Tags: upstream Since there is no distinct pd-osc upstream, there are no separate releases from the upstream author only svn, and the only circulating release is the is the 'mrpeach' library included in Pd-extended, I think we need to first get this stuff organized upstream before uploading a package to Debian. Have you talked with Martin Peach about it? I think it makes sense to have pd-osc, but I think the upstream author should determine how the code is released. The 'mrpeach' thing could be dropped, for example, if Martin wants it that way. .hc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk33ZAEACgkQkX2Xpv6ydvSN8ACeOL5AKdtccX+xl5Q0xrkoGHnt QmAAnR1TlHVcbqkaf3DqFdXL2Qsvpm7r =Wwm4 -END PGP SIGNATURE- - ¡El pueblo unido jamás será vencido! -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) iQIcBAEBCAAGBQJN949qAAoJEJ8P5Yc3S76BXCgP/jz2r2ZUjtsplHKWTSDgvxwZ bXGeoi89+FMVbNQRnaeZEB+SKCPvzTZaWvp6vuNS9YSoQZs48zFZ+hlvpgJmsIxY Vw3BsGrwb7Lf4JC1fq3Ww0f1E890NfsFklwpwetSIhsLhIjBmNOod/0fB/SAoCzW 5AfA+6Uh9/HLYhSjNEEOrtufKjjVfRU8Tlp3jX+2JjmBt60B+m3Ev6EbmzL8904L Izu7BloWLYyDQkKaNYsFz0aKkSWbtpY2+lBC/Yw8D9k1qhbnaacz5EdFlVmjKw8p OKR7To5W9ieu/B1r2srl49sFA8W+9NQv+QXX79TwNE7aaza6KwDp8bCLXYe2knec e6Vjs/9qbAEgjO/RF8oGsSwQsjyXYWYGKV99MdKA8+8gykkNTJJUMepXrDjZfleG m151+tDkGhBcyyTBZ2yun8V9m09a8cyQEXuByn48jjpUrdfKnc7IMFndPCeHVIi9 u8NpM3pp6V7pCKdyY9nwN/wKJBsqSMdp87pap1woAGITq1BsiarXyYMRnOt/MX4b JR0Z3qObFusH5Su1YEnU+syrOXlt6a8R6vEXvt2LcN5kTqkVy5k2ymtWgJNrebDv DPKUmzd60vqyux2xCs0IqCK4+DKLUP97WZ56gLaJqGPzqT85Hv/4I/h5mbZxllqu 2CDDjARNif2/Ca+OEn8Y =9/ut -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/59fb9288-965b-4186-ab15-ac235889e...@eds.org
Bug#603175: pd-osc (was Re: Bug#603175: reorganize upstream first)
Hi IOhannes, Yes go ahead. I've been wanting to do that as well. The name 'mrpeach' is not very useful. Martin On 14/06/11 09:37 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi martin, in the process of getting numerous pd-libraries into debian (and thus ubuntu and other debian derivatives), we stumbled upon a small issue in your set of objects. as things are right now, there are no "upstream releases" of your libraries; in SVN they are organized (as you are well aware) into a mrpeach/ folder with various task-specific sub-folders. historically, Pd-extended used the mrpeach/ folder as an organizational unit. (install everything you created into a flat extra/mrpeach/ folder) however, since your libraries don't have anything in common apart from you as the author, i would prefer to package them into separate packages, according to the tasks they are associated with (at least those where there i a notion of 'library' as is the case with your net-, osc-, cmos- objects, so people can install "pd-osc" if they need OSC communication (and don't need your net/ implementation, as they intend to send OSC over serial/slip). the rough idea is to have packages for - - OSC - - net - - cmos - - midifile - - binfile - - slip - - str - - oscillators - - tabletools - - which the debian packages would be named accordingly, with "pd-" prepended (or "pd-mrpeach-" for generic names like "tabletools" and "oscillators", in order to distinguish them from other libraries that could claim those generic names with equal rights) eventually i'm planning to have a "pd-mrpeach" meta-package that would depend on all these sub-packages and provide a compatibility layer for older (pd-extended) patches. nothing is required from you to actually _do_ (e.g. code-wise), but as hans has correctly pointed out, it would be good to know your feelings about all this. cheers fgamsdr IOhannes On 2011-06-13 17:26, Hans-Christoph Steiner wrote: Tags: upstream Since there is no distinct pd-osc upstream, there are no separate releases from the upstream author only svn, and the only circulating release is the is the 'mrpeach' library included in Pd-extended, I think we need to first get this stuff organized upstream before uploading a package to Debian. Have you talked with Martin Peach about it? I think it makes sense to have pd-osc, but I think the upstream author should determine how the code is released. The 'mrpeach' thing could be dropped, for example, if Martin wants it that way. .hc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk33ZAEACgkQkX2Xpv6ydvSN8ACeOL5AKdtccX+xl5Q0xrkoGHnt QmAAnR1TlHVcbqkaf3DqFdXL2Qsvpm7r =Wwm4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp31a12af98acbbfd74e06dded...@phx.gbl
Bug#603175: pd-osc (was Re: Bug#603175: reorganize upstream first)
These clearly make sense as standalone libs: osc net cmos oscillators tabletools str But which, binfile, and midifile might be better in some kind of library. Like perhaps some kind of 'file' library for binfile and midifile, that lib could include a whole suite of objects to read differernt files. Or maybe midifile belongs in a midi lib, which seems kind of like iemguts, as so on and so forth... .hc On Jun 14, 2011, at 12:38 PM, Martin wrote: Hi IOhannes, Yes go ahead. I've been wanting to do that as well. The name 'mrpeach' is not very useful. Martin On 14/06/11 09:37 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi martin, in the process of getting numerous pd-libraries into debian (and thus ubuntu and other debian derivatives), we stumbled upon a small issue in your set of objects. as things are right now, there are no "upstream releases" of your libraries; in SVN they are organized (as you are well aware) into a mrpeach/ folder with various task-specific sub-folders. historically, Pd-extended used the mrpeach/ folder as an organizational unit. (install everything you created into a flat extra/mrpeach/ folder) however, since your libraries don't have anything in common apart from you as the author, i would prefer to package them into separate packages, according to the tasks they are associated with (at least those where there i a notion of 'library' as is the case with your net-, osc-, cmos- objects, so people can install "pd-osc" if they need OSC communication (and don't need your net/ implementation, as they intend to send OSC over serial/slip). the rough idea is to have packages for - - OSC - - net - - cmos - - midifile - - binfile - - slip - - str - - oscillators - - tabletools - - which the debian packages would be named accordingly, with "pd-" prepended (or "pd-mrpeach-" for generic names like "tabletools" and "oscillators", in order to distinguish them from other libraries that could claim those generic names with equal rights) eventually i'm planning to have a "pd-mrpeach" meta-package that would depend on all these sub-packages and provide a compatibility layer for older (pd-extended) patches. nothing is required from you to actually _do_ (e.g. code-wise), but as hans has correctly pointed out, it would be good to know your feelings about all this. cheers fgamsdr IOhannes On 2011-06-13 17:26, Hans-Christoph Steiner wrote: Tags: upstream Since there is no distinct pd-osc upstream, there are no separate releases from the upstream author only svn, and the only circulating release is the is the 'mrpeach' library included in Pd-extended, I think we need to first get this stuff organized upstream before uploading a package to Debian. Have you talked with Martin Peach about it? I think it makes sense to have pd-osc, but I think the upstream author should determine how the code is released. The 'mrpeach' thing could be dropped, for example, if Martin wants it that way. .hc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk33ZAEACgkQkX2Xpv6ydvSN8ACeOL5AKdtccX+xl5Q0xrkoGHnt QmAAnR1TlHVcbqkaf3DqFdXL2Qsvpm7r =Wwm4 -END PGP SIGNATURE- Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d9014b35-0195-4311-b868-8bef35259...@eds.org
