Bug#312740: Request regarding ROTE library
On Thu, Jul 07, 2005 at 10:50:02PM -0300, Bruno Oliveira wrote: Ok folks, the new release (0.2.8) is out and includes a new function: rote_vt_get_pty_fd, which returns the pty's file descriptor. Phil should be able to use this in order to eliminate the need to include roteprivate.h... As for generating the rote.la file, I don't know how to do that since I don't use libtool :-) If any of you would care to send me a patch, that would be nice. I'll eventually learn libtool but not in the near future.. Bruno, Thanks for all the work. I will have the new version packaged and uploaded fairly soon. The 0.2.6+20050511 still has not made it out of the NEW queue and into unstable, but it will be there soon, as it has been about a week. In the mean time, the packages are still available on my website. As soon as Phil modifies anyterm to work with the new ROTE version, I will package and have anyterm uploaded to Sid. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpJPFEf1DblB.pgp Description: PGP signature
Bug#312740: Request regarding ROTE library
Ok folks, the new release (0.2.8) is out and includes a new function: rote_vt_get_pty_fd, which returns the pty's file descriptor. Phil should be able to use this in order to eliminate the need to include roteprivate.h... As for generating the rote.la file, I don't know how to do that since I don't use libtool :-) If any of you would care to send me a patch, that would be nice. I'll eventually learn libtool but not in the near future.. Best regards, Bruno T. C. de Oliveira On 6/27/05, Roberto C. Sanchez [EMAIL PROTECTED] wrote: Bruno, Thanks for the reply. A new release soon after the change would be nice. If not, please let us know and I can grab a new CVS snapshot with which to package a new Debian version. Phil, As soon as the dependency on roteprivate.h can be removed, the way will be clear for an official Debian package. It should be only a few days after you make the new version of anyterm available that a package will be in Sid. -Roberto On Mon, Jun 27, 2005 at 12:20:54AM -0300, Bruno Oliveira wrote: a patch to add that funcionality would be most welcome. As for the reading of the pty descriptor, I guess there should be an interface function for returning it, rather than moving the field to rote.h. That way binary compatibility won't be broken. I'm a little short on time so I'll do those modifications after july 4. But if any of you want to send me a patch for that I'll apply it right away! Thanks for the continued interest in my software, Bruno On 6/23/05, Roberto C. Sanchez [EMAIL PROTECTED] wrote: Bruno, I am working on packaging your ROTE library for Debian, as I am also packaging anyterm, which depends on ROTE. I have a couple of requests. First, would it be possible for you to modify the library build process to create a librote.a and librote.la for inclusion in the development version of the library package? Second, would it be possible for you to include the information from roteprivate.h used by anyterm [0] in the rote.h header? I ask this becuase it is not possible for the Debian package build system to make roteprivate.h, which is only in the source of rote, available during the build of anyterm. This leaves only a couple of options, none of which are acceptable. Specifically, the anyterm pacakge would need to include a copy of roteprivate.h (which would couple the two packages too tightly), or Phil would need to include a copy of the rote source in anyterm, which misses the point of a library. I have emailed Phil about this, but this is not a very high priority for him since the current setup works for him and the changes we need to make this happen will cause you difficulties by breaking binary compatibility in your library. If you would be willing to accept patches for inclusion in the next release or if there is anything else we can do, please let me know. -Roberto [0] http://anyterm.org/1.1/install.html -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- Bruno Takahashi C. de Oliveira -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- Bruno Takahashi C. de Oliveira
Bug#312740: Request regarding ROTE library
Bruno, Thanks for the reply. A new release soon after the change would be nice. If not, please let us know and I can grab a new CVS snapshot with which to package a new Debian version. Phil, As soon as the dependency on roteprivate.h can be removed, the way will be clear for an official Debian package. It should be only a few days after you make the new version of anyterm available that a package will be in Sid. -Roberto On Mon, Jun 27, 2005 at 12:20:54AM -0300, Bruno Oliveira wrote: a patch to add that funcionality would be most welcome. As for the reading of the pty descriptor, I guess there should be an interface function for returning it, rather than moving the field to rote.h. That way binary compatibility won't be broken. I'm a little short on time so I'll do those modifications after july 4. But if any of you want to send me a patch for that I'll apply it right away! Thanks for the continued interest in my software, Bruno On 6/23/05, Roberto C. Sanchez [EMAIL PROTECTED] wrote: Bruno, I am working on packaging your ROTE library for Debian, as I am also packaging anyterm, which depends on ROTE. I have a couple of requests. First, would it be possible for you to modify the library build process to create a librote.a and librote.la for inclusion in the development version of the library package? Second, would it be possible for you to include the information from roteprivate.h used by anyterm [0] in the rote.h header? I ask this becuase it is not possible for the Debian package build system to make roteprivate.h, which is only in the source of rote, available during the build of anyterm. This leaves only a couple of options, none of which are acceptable. Specifically, the anyterm pacakge would need to include a copy of roteprivate.h (which would couple the two packages too tightly), or Phil would need to include a copy of the rote source in anyterm, which misses the point of a library. I have emailed Phil about this, but this is not a very high priority for him since the current setup works for him and the changes we need to make this happen will cause you difficulties by breaking binary compatibility in your library. If you would be willing to accept patches for inclusion in the next release or if there is anything else we can do, please let me know. -Roberto [0] http://anyterm.org/1.1/install.html -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- Bruno Takahashi C. de Oliveira -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpRqDhedI0sZ.pgp Description: PGP signature
Bug#312740: Request regarding ROTE library
a patch to add that funcionality would be most welcome. As for the reading of the pty descriptor, I guess there should be an interface function for returning it, rather than moving the field to rote.h. That way binary compatibility won't be broken. I'm a little short on time so I'll do those modifications after july 4. But if any of you want to send me a patch for that I'll apply it right away! Thanks for the continued interest in my software, Bruno On 6/23/05, Roberto C. Sanchez [EMAIL PROTECTED] wrote: Bruno, I am working on packaging your ROTE library for Debian, as I am also packaging anyterm, which depends on ROTE. I have a couple of requests. First, would it be possible for you to modify the library build process to create a librote.a and librote.la for inclusion in the development version of the library package? Second, would it be possible for you to include the information from roteprivate.h used by anyterm [0] in the rote.h header? I ask this becuase it is not possible for the Debian package build system to make roteprivate.h, which is only in the source of rote, available during the build of anyterm. This leaves only a couple of options, none of which are acceptable. Specifically, the anyterm pacakge would need to include a copy of roteprivate.h (which would couple the two packages too tightly), or Phil would need to include a copy of the rote source in anyterm, which misses the point of a library. I have emailed Phil about this, but this is not a very high priority for him since the current setup works for him and the changes we need to make this happen will cause you difficulties by breaking binary compatibility in your library. If you would be willing to accept patches for inclusion in the next release or if there is anything else we can do, please let me know. -Roberto [0] http://anyterm.org/1.1/install.html -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- Bruno Takahashi C. de Oliveira
Bug#312740: Request regarding ROTE library
Bruno, I am working on packaging your ROTE library for Debian, as I am also packaging anyterm, which depends on ROTE. I have a couple of requests. First, would it be possible for you to modify the library build process to create a librote.a and librote.la for inclusion in the development version of the library package? Second, would it be possible for you to include the information from roteprivate.h used by anyterm [0] in the rote.h header? I ask this becuase it is not possible for the Debian package build system to make roteprivate.h, which is only in the source of rote, available during the build of anyterm. This leaves only a couple of options, none of which are acceptable. Specifically, the anyterm pacakge would need to include a copy of roteprivate.h (which would couple the two packages too tightly), or Phil would need to include a copy of the rote source in anyterm, which misses the point of a library. I have emailed Phil about this, but this is not a very high priority for him since the current setup works for him and the changes we need to make this happen will cause you difficulties by breaking binary compatibility in your library. If you would be willing to accept patches for inclusion in the next release or if there is anything else we can do, please let me know. -Roberto [0] http://anyterm.org/1.1/install.html -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpzVgPd726Go.pgp Description: PGP signature
