Re: adding a binary package to pd-cyclone
On Fri, Dec 31, 2010 at 02:51, Hans-Christoph Steiner h...@at.or.at wrote: On Thu, 2010-12-30 at 00:53 +0100, Jonas Smedegaard wrote: On Wed, Dec 29, 2010 at 08:14:57PM -0300, Felipe Sateler wrote: You edited debian/control, but Jonas added debian/control.in for build-dependencies autogeneration. If you disagree about the use of debian/control.in, we should disable it. If not, we should use it. But having it and not using it does not seem a sane option. I suggest we only drop the control.in if noone use the .in file or it annoys someone. I see no big problem in some of us editing the control file directly - the nuissence of sync'ing changes there to the .in file is shadowed by the benefit of dependency semi-autoresolving IMO. (please do edit the .in file rather than the control file if you want to help minimize work for everyone, though) Ok, I hope its alright with everyone, I removed the control.in. I can see using automatic build-depends generation on a package with complex Build-Depends, but this one is really simple, and I think the Build-Depends will rarely change, if ever. From my experience, build products should not be in git (i.e. the 'control' file generated using 'control.in'). Since that doesn't seem possible for 'control', I think we'll be better off by simplifying to a static 'control'. Uploading. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Fri, Dec 31, 2010 at 12:51:47AM -0500, Hans-Christoph Steiner wrote: On Thu, 2010-12-30 at 00:53 +0100, Jonas Smedegaard wrote: On Wed, Dec 29, 2010 at 08:14:57PM -0300, Felipe Sateler wrote: You edited debian/control, but Jonas added debian/control.in for build-dependencies autogeneration. If you disagree about the use of debian/control.in, we should disable it. If not, we should use it. But having it and not using it does not seem a sane option. I suggest we only drop the control.in if noone use the .in file or it annoys someone. I see no big problem in some of us editing the control file directly - the nuissence of sync'ing changes there to the .in file is shadowed by the benefit of dependency semi-autoresolving IMO. (please do edit the .in file rather than the control file if you want to help minimize work for everyone, though) Ok, I hope its alright with everyone, I removed the control.in. I can see using automatic build-depends generation on a package with complex Build-Depends, but this one is really simple, and I think the Build-Depends will rarely change, if ever. If you mean to say that the control.in annoys you, then fine. If, on the other hand, you mean to say that you guess noone use the .in file then you're wrong: I use it (as long as noone is annoyed by it). Currently @cdbs@ resolves to cdbs, debhelper (= 6), dh-buildinfo. As an example, if at some point debhelper compat level is bumped to 7, I bet manual build-dependency handling would be to just tighten to debhelper (= 7) but that is wrong - cdbs needs to be tightened too due to a bug in early implementations of debhelper 7 support in CDBS, and also (still in dispute, though - Joy disagrees with this!) build-dependency on debhelper itself is tightened further than just 7 as well, because not all of the core debhelper 7 features was implemented initially. From my experience, build products should not be in git (i.e. the 'control' file generated using 'control.in'). Since that doesn't seem possible for 'control', I think we'll be better off by simplifying to a static 'control'. I disagree. Some files make sense only to autogenerate by the respective code developers, and then (normally) shipped with the code and treated as source by users of the code. Examples of this is Makefile files (when automake is used), Makefile.in files and configure (when autoconf is used) and debian/control (when CDBS dependency-resolving is used). For autotools it is possible to help distinguish between user and maintainer modes of operation with an optional configure flag --maintainer-mode, and similarly CDBS has DEB_MAINTAINER_MODE. - 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/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Dec 31, 2010, at 8:11 AM, Jonas Smedegaard wrote: On Fri, Dec 31, 2010 at 12:51:47AM -0500, Hans-Christoph Steiner wrote: On Thu, 2010-12-30 at 00:53 +0100, Jonas Smedegaard wrote: On Wed, Dec 29, 2010 at 08:14:57PM -0300, Felipe Sateler wrote: You edited debian/control, but Jonas added debian/control.in for build-dependencies autogeneration. If you disagree about the use of debian/control.in, we should disable it. If not, we should use it. But having it and not using it does not seem a sane option. I suggest we only drop the control.in if noone use the .in file or it annoys someone. I see no big problem in some of us editing the control file directly - the nuissence of sync'ing changes there to the .in file is shadowed by the benefit of dependency semi-autoresolving IMO. (please do edit the .in file rather than the control file if you want to help minimize work for everyone, though) Ok, I hope its alright with everyone, I removed the control.in. I can see using automatic build-depends generation on a package with complex Build-Depends, but this one is really simple, and I think the Build-Depends will rarely change, if ever. If you mean to say that the control.in annoys you, then fine. If, on the other hand, you mean to say that you guess noone use the .in file then you're wrong: I use it (as long as noone is annoyed by it). Currently @cdbs@ resolves to cdbs, debhelper (= 6), dh-buildinfo. As an example, if at some point debhelper compat level is bumped to 7, I bet manual build-dependency handling would be to just tighten to debhelper (= 7) but that is wrong - cdbs needs to be tightened too due to a bug in early implementations of debhelper 7 support in CDBS, and also (still in dispute, though - Joy disagrees with this!) build-dependency on debhelper itself is tightened further than just 7 as well, because not all of the core debhelper 7 features was implemented initially. For the record, I'm not saying that no one uses the file, or that the automatic Build-Depends handling isn't useful. I'm saying I think in this package, the benefits of the control.in are smaller than the disadvantages. .hc From my experience, build products should not be in git (i.e. the 'control' file generated using 'control.in'). Since that doesn't seem possible for 'control', I think we'll be better off by simplifying to a static 'control'. I disagree. Some files make sense only to autogenerate by the respective code developers, and then (normally) shipped with the code and treated as source by users of the code. Examples of this is Makefile files (when automake is used), Makefile.in files and configure (when autoconf is used) and debian/control (when CDBS dependency-resolving is used). For autotools it is possible to help distinguish between user and maintainer modes of operation with an optional configure flag -- maintainer-mode, and similarly CDBS has DEB_MAINTAINER_MODE. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Fri, Dec 31, 2010 at 11:49:53AM -0500, Hans-Christoph Steiner wrote: On Dec 31, 2010, at 8:11 AM, Jonas Smedegaard wrote: On Fri, Dec 31, 2010 at 12:51:47AM -0500, Hans-Christoph Steiner wrote: On Thu, 2010-12-30 at 00:53 +0100, Jonas Smedegaard wrote: I suggest we only drop the control.in if noone use the .in file or it annoys someone. [...] Ok, I hope its alright with everyone, I removed the control.in. [...] If you mean to say that the control.in annoys you, then fine. If, on the other hand, you mean to say that you guess noone use the .in file then you're wrong: I use it (as long as noone is annoyed by it). [...] For the record, I'm not saying that no one uses the file, or that the automatic Build-Depends handling isn't useful. I'm saying I think in this package, the benefits of the control.in are smaller than the disadvantages. For the record I am perfectly fine with dropping control.in in this package or any other package - as long as noone uses it or it annoys someone. If, on the other hand, someone use it and it does not annoy anyone - in this package or any other package - then it seems odd to rip it out. I am talking about in this package - and have been in all of the parts quoted above. I gave an example (not quoted here to try avoid confusion) on how even if currently dependency resolving in this package is simple, it might not be in the future, which I find a valid reason to continue using that feature of CDBS in this package as well as other ones which you might consider so simple that you might want to rip it out from. Let me repeat: I suggest we only drop the control.in if noone use the .in file or it annoys someone. In this package. Kind regards - and happy new year to all, - 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/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Thu, 2010-12-30 at 00:53 +0100, Jonas Smedegaard wrote: On Wed, Dec 29, 2010 at 08:14:57PM -0300, Felipe Sateler wrote: You edited debian/control, but Jonas added debian/control.in for build-dependencies autogeneration. If you disagree about the use of debian/control.in, we should disable it. If not, we should use it. But having it and not using it does not seem a sane option. I suggest we only drop the control.in if noone use the .in file or it annoys someone. I see no big problem in some of us editing the control file directly - the nuissence of sync'ing changes there to the .in file is shadowed by the benefit of dependency semi-autoresolving IMO. (please do edit the .in file rather than the control file if you want to help minimize work for everyone, though) Ok, I hope its alright with everyone, I removed the control.in. I can see using automatic build-depends generation on a package with complex Build-Depends, but this one is really simple, and I think the Build-Depends will rarely change, if ever. From my experience, build products should not be in git (i.e. the 'control' file generated using 'control.in'). Since that doesn't seem possible for 'control', I think we'll be better off by simplifying to a static 'control'. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Wed, Dec 29, 2010 at 16:29, Hans-Christoph Steiner h...@at.or.at wrote: On Dec 27, 2010, at 4:09 AM, Felipe Sateler wrote: On Mon, Dec 27, 2010 at 02:09, Hans-Christoph Steiner h...@at.or.at wrote: On Dec 25, 2010, at 6:34 AM, Felipe Sateler wrote: On Fri, Dec 24, 2010 at 14:55, Hans-Christoph Steiner h...@at.or.at wrote: On Dec 24, 2010, at 9:41 AM, Jonas Smedegaard wrote: On Fri, Dec 24, 2010 at 02:10:27PM -0300, Felipe Sateler wrote: On Fri, Dec 24, 2010 at 00:27, Hans-Christoph Steiner h...@at.or.at wrote: I just pushed some changes to pd-cyclone that create a split-out binary package called 'cyclist'. As far as I understand it, I don't need to ITP this new 'cyclist' package since its split off of the pd-cyclone source package, but it does need to go thru the NEW queue. 'cyclist' is a command line utility for converting file formats that is built as part of the 'cyclone' library. Its the only thing in 'pd-cyclone' that installs into /usr/bin and has a man page, so it made sense to me to split it out. Then it can be installed on its own without puredata or any Pd libraries. Its ready for a sponsor/uploader if you are ready for it. :) It seems to me there isn't much point in having the cyclist binary without pd. What is the use case of converting Max/MSP patches into text, if not for importing into pd? A search engine, perhaps? It would be useful to Max/MSP users separate from Pd. And perhaps also useful to other computer music people. The binary file format is really only for Max/MSP, but the text file format is quite old, and used by a number of other members of the Max family. Pd and jMax for example, which are free software, and Max/FTS and Max/ISPW which are specialty proprietary versions of Max. OK. The Recommends on cyclist by pd-cyclone is not clear to me. If these tools have different use cases, then maybe recommends is too strong a relationship. Since the central goal of the 'cyclone' library is for running Max/MSP files in Pd, and Max/MSP patches are usually distributed in the .mxb binary format, I think it makes sense to Recommend: cyclist so that 'cyclone' users can translate .mxb files to .pat/.mxt files, which Pd can directly read. So, if I understand correctly, pd users still need to run cyclist, even if they have pd-cyclone installed? Yes, cyclist is only for converting the Max/MSP-specific binary .mxb format to the more widely implemented text format .mxt/.pat. pd-cyclone is a library that allows Pd to act more like Max/MSP, but Pd only reads the .mxt/.pat format. OK then. You edited debian/control, but Jonas added debian/control.in for build-dependencies autogeneration. If you disagree about the use of debian/control.in, we should disable it. If not, we should use it. But having it and not using it does not seem a sane option. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Wed, Dec 29, 2010 at 08:14:57PM -0300, Felipe Sateler wrote: You edited debian/control, but Jonas added debian/control.in for build-dependencies autogeneration. If you disagree about the use of debian/control.in, we should disable it. If not, we should use it. But having it and not using it does not seem a sane option. I suggest we only drop the control.in if noone use the .in file or it annoys someone. I see no big problem in some of us editing the control file directly - the nuissence of sync'ing changes there to the .in file is shadowed by the benefit of dependency semi-autoresolving IMO. (please do edit the .in file rather than the control file if you want to help minimize work for everyone, though) - 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/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Fri, Dec 24, 2010 at 14:55, Hans-Christoph Steiner h...@at.or.at wrote: On Dec 24, 2010, at 9:41 AM, Jonas Smedegaard wrote: On Fri, Dec 24, 2010 at 02:10:27PM -0300, Felipe Sateler wrote: On Fri, Dec 24, 2010 at 00:27, Hans-Christoph Steiner h...@at.or.at wrote: I just pushed some changes to pd-cyclone that create a split-out binary package called 'cyclist'. As far as I understand it, I don't need to ITP this new 'cyclist' package since its split off of the pd-cyclone source package, but it does need to go thru the NEW queue. 'cyclist' is a command line utility for converting file formats that is built as part of the 'cyclone' library. Its the only thing in 'pd-cyclone' that installs into /usr/bin and has a man page, so it made sense to me to split it out. Then it can be installed on its own without puredata or any Pd libraries. Its ready for a sponsor/uploader if you are ready for it. :) It seems to me there isn't much point in having the cyclist binary without pd. What is the use case of converting Max/MSP patches into text, if not for importing into pd? A search engine, perhaps? It would be useful to Max/MSP users separate from Pd. And perhaps also useful to other computer music people. The binary file format is really only for Max/MSP, but the text file format is quite old, and used by a number of other members of the Max family. Pd and jMax for example, which are free software, and Max/FTS and Max/ISPW which are specialty proprietary versions of Max. OK. The Recommends on cyclist by pd-cyclone is not clear to me. If these tools have different use cases, then maybe recommends is too strong a relationship. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Fri, Dec 24, 2010 at 00:27, Hans-Christoph Steiner h...@at.or.at wrote: I just pushed some changes to pd-cyclone that create a split-out binary package called 'cyclist'. As far as I understand it, I don't need to ITP this new 'cyclist' package since its split off of the pd-cyclone source package, but it does need to go thru the NEW queue. 'cyclist' is a command line utility for converting file formats that is built as part of the 'cyclone' library. Its the only thing in 'pd-cyclone' that installs into /usr/bin and has a man page, so it made sense to me to split it out. Then it can be installed on its own without puredata or any Pd libraries. Its ready for a sponsor/uploader if you are ready for it. :) It seems to me there isn't much point in having the cyclist binary without pd. What is the use case of converting Max/MSP patches into text, if not for importing into pd? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Fri, Dec 24, 2010 at 02:10:27PM -0300, Felipe Sateler wrote: On Fri, Dec 24, 2010 at 00:27, Hans-Christoph Steiner h...@at.or.at wrote: I just pushed some changes to pd-cyclone that create a split-out binary package called 'cyclist'. As far as I understand it, I don't need to ITP this new 'cyclist' package since its split off of the pd-cyclone source package, but it does need to go thru the NEW queue. 'cyclist' is a command line utility for converting file formats that is built as part of the 'cyclone' library. Its the only thing in 'pd-cyclone' that installs into /usr/bin and has a man page, so it made sense to me to split it out. Then it can be installed on its own without puredata or any Pd libraries. Its ready for a sponsor/uploader if you are ready for it. :) It seems to me there isn't much point in having the cyclist binary without pd. What is the use case of converting Max/MSP patches into text, if not for importing into pd? A search engine, perhaps? - 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/mailman/listinfo/pkg-multimedia-maintainers
Re: adding a binary package to pd-cyclone
On Dec 24, 2010, at 9:41 AM, Jonas Smedegaard wrote: On Fri, Dec 24, 2010 at 02:10:27PM -0300, Felipe Sateler wrote: On Fri, Dec 24, 2010 at 00:27, Hans-Christoph Steiner h...@at.or.at wrote: I just pushed some changes to pd-cyclone that create a split-out binary package called 'cyclist'. As far as I understand it, I don't need to ITP this new 'cyclist' package since its split off of the pd-cyclone source package, but it does need to go thru the NEW queue. 'cyclist' is a command line utility for converting file formats that is built as part of the 'cyclone' library. Its the only thing in 'pd-cyclone' that installs into /usr/bin and has a man page, so it made sense to me to split it out. Then it can be installed on its own without puredata or any Pd libraries. Its ready for a sponsor/uploader if you are ready for it. :) It seems to me there isn't much point in having the cyclist binary without pd. What is the use case of converting Max/MSP patches into text, if not for importing into pd? A search engine, perhaps? It would be useful to Max/MSP users separate from Pd. And perhaps also useful to other computer music people. The binary file format is really only for Max/MSP, but the text file format is quite old, and used by a number of other members of the Max family. Pd and jMax for example, which are free software, and Max/FTS and Max/ISPW which are specialty proprietary versions of Max. .hc A cellphone to me is just an opportunity to be irritated wherever you are. - Linus Torvalds ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
adding a binary package to pd-cyclone
I just pushed some changes to pd-cyclone that create a split-out binary package called 'cyclist'. As far as I understand it, I don't need to ITP this new 'cyclist' package since its split off of the pd- cyclone source package, but it does need to go thru the NEW queue. 'cyclist' is a command line utility for converting file formats that is built as part of the 'cyclone' library. Its the only thing in 'pd- cyclone' that installs into /usr/bin and has a man page, so it made sense to me to split it out. Then it can be installed on its own without puredata or any Pd libraries. Its ready for a sponsor/uploader if you are ready for it. :) .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
