Bug#638760: Removal of grace, pygrace and expeyes
On 23/03/2014 01:50, Drew Parsons wrote: On Sat, 2014-03-22 at 20:07 -0400, Michael Gilbert wrote: On Sat, Mar 22, 2014 at 8:01 PM, Drew Parsons wrote: Grace is one of the most useful packages in the entire archive. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. That can be fixed by anyone willing to spend the time to update it to use freetype. Removing the package will likely provide an incentive for someone sufficiently skilled and interested to do that, and it will eventually be back. At the core of it, lib/canvas/t1fonts.c would need to be replaced, and Canvas in include/grace/canvasP.h and various client code points would need to be updated to match. Sounds like a worthy candidate for the Google Summer of Code. Too late for the GSoC (deadline for students was last Friday) and I don't think we would have accepted this as a project. Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On Sun, 23 Mar 2014 11:01:39 +1100 Drew Parsons dpars...@debian.org wrote: Grace is one of the most useful packages in the entire archive. ... for 0.34% of users of the archive, maybe. To me, it is simply an RC buggy package which has had no new development upstream since 2012 and which depends on an obsolete, abandoned library. Unless it can be ported, it will need to be removed alongside t1lib. Those who care about grace need to scratch their own itch and fix it. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. Removing it is necessary, as explained. t1lib has been superseded and packages which used to use it need to migrate. The other packages have already done so, those which fail to do so cannot be supported when the underlying dependency has been abandoned. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#638760: Removal of grace, pygrace and expeyes
On Sat, 22 Mar 2014 20:38:49 -0700 Nicholas Breen nbr...@debian.org wrote: On Sat, Mar 22, 2014 at 04:10:39PM +, Neil Williams wrote: I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. If just getting standalone t1lib out of the archive is the goal, I don't mind incorporating all of the existing t1lib patches into the embedded copy. No. How does that solve the problem of t1lib being abandoned upstream and already superseded by freetype? As grace is almost exclusively used to plot locally-supplied numeric data, and is not in any way practical to use in a network setting, it has minimal security risk vs. some other former users of t1lib like php5. The security issues were only one part of this - t1lib has been abandoned and superseded. It is unsupportable, as are packages which rely on it. If getting t1lib in all its forms out of the archive is the goal, then yes, grace would have to be removed. Rewriting it is not practical and there doesn't seem to be anyone with the time + desire + skillset to adopt t1lib. However, there's also no real replacement for grace itself available. OK, so that is confirmation that grace will have to be removed once t1lib itself is removed and that reverse dependencies of grace like expeyes need to migrate away from grace. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#638760: Removal of grace, pygrace and expeyes
Hello, I'm the [passive] upstream maintainer. Just to make things clear: 1. grace is perfectly happy using its own copy of t1lib. So you can safely remove the t1lib debian package. 2. Yes, perhaps only 0.34% of all users use it. But same can be said about 90% of the entire debian archive (for each package separately, of course). 3. Yes, it is potentially buggy and insecure. But since in 99.9% you use it within the projects you work yourself on, nothing wrong can happen. In the worst case you loose some time. (And in my experience, grace crashes MUCH less frequently than some high-profile softwares which are really exposed to the Internet.) 4. I have no time and intention right now to switch to freetype. For the scope it is currently used in grace, t1lib is adequate. When I come across a bug, I fix it - that's how the bundled t1lib copy got emerged in the first place. Best, Evgeny On 23/03/14 12:01, Neil Williams wrote: On Sun, 23 Mar 2014 11:01:39 +1100 Drew Parsons dpars...@debian.org wrote: Grace is one of the most useful packages in the entire archive. ... for 0.34% of users of the archive, maybe. To me, it is simply an RC buggy package which has had no new development upstream since 2012 and which depends on an obsolete, abandoned library. Unless it can be ported, it will need to be removed alongside t1lib. Those who care about grace need to scratch their own itch and fix it. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. Removing it is necessary, as explained. t1lib has been superseded and packages which used to use it need to migrate. The other packages have already done so, those which fail to do so cannot be supported when the underlying dependency has been abandoned. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On Sun, Mar 23, 2014 at 10:03:53AM +, Neil Williams wrote: On Sat, 22 Mar 2014 20:38:49 -0700 Nicholas Breen nbr...@debian.org wrote: On Sat, Mar 22, 2014 at 04:10:39PM +, Neil Williams wrote: I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. If just getting standalone t1lib out of the archive is the goal, I don't mind incorporating all of the existing t1lib patches into the embedded copy. No. How does that solve the problem of t1lib being abandoned upstream and already superseded by freetype? Why is it a problem in the first place? Software is being rewritten and superseded constantly, this doesn't mean other software using those old libraries are immediately to be sent to the bin. I think this is the grace's maintainer's call. But then maybe I am missing part of the conversatio and your motivation to have grace removed. As grace is almost exclusively used to plot locally-supplied numeric data, and is not in any way practical to use in a network setting, it has minimal security risk vs. some other former users of t1lib like php5. The security issues were only one part of this - t1lib has been abandoned and superseded. It is unsupportable, as are packages which rely on it. It is being supported by grace upstream as part of the embedded library, as written elsewhere on this thread. For some values of supported, but I don't see the point in removing grace completely. If you want to get rid of the the t1lib package - fine, but I think using the embedded copy is an acceptable solution for grace. Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On Sun, 23 Mar 2014 13:08:14 +0100 Michael Banck mba...@debian.org wrote: On Sun, Mar 23, 2014 at 10:03:53AM +, Neil Williams wrote: On Sat, 22 Mar 2014 20:38:49 -0700 Nicholas Breen nbr...@debian.org wrote: On Sat, Mar 22, 2014 at 04:10:39PM +, Neil Williams wrote: I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. If just getting standalone t1lib out of the archive is the goal, I don't mind incorporating all of the existing t1lib patches into the embedded copy. No. How does that solve the problem of t1lib being abandoned upstream and already superseded by freetype? Why is it a problem in the first place? Software is being rewritten and superseded constantly, this doesn't mean other software using those old libraries are immediately to be sent to the bin. It's not immediate. t1lib has had no upstream changes in Debian since 2008! grace itself has not had upstream changes introduced into Debian since the same time. Abandoned software doesn't need to bit rot forever in Debian. If there is reason to keep it, there is reason for someone to maintain it. Whilst it remains orphaned, it will be considered unmaintained, abandoned and suitable for removal. I think this is the grace's maintainer's call. But then maybe I am missing part of the conversatio and your motivation to have grace removed. Personally, I don't think it is good to have an embedded copy of a removed package inside a package which remains in the archive. What would be needed is an assurance from the grace maintainer and those who are keen to retain grace in Debian, that the internal t1lib code would be maintained inside grace to a better standard than it has so far been maintained outside grace. That may be simpler to do if the grace maintainer interested parties adopt t1lib (upstream and in Debian). At that point, the problem with t1lib become manageable again. That would close #637488 and #638760 at the same time. As grace is almost exclusively used to plot locally-supplied numeric data, and is not in any way practical to use in a network setting, it has minimal security risk vs. some other former users of t1lib like php5. The security issues were only one part of this - t1lib has been abandoned and superseded. It is unsupportable, as are packages which rely on it. It is being supported by grace upstream as part of the embedded library, as written elsewhere on this thread. For some values of supported, but I don't see the point in removing grace completely. If you want to get rid of the the t1lib package - fine, but I think using the embedded copy is an acceptable solution for grace. This would need to be declared clearly in the grace package description and maintained as part of grace. It's not the ideal solution. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#638760: Removal of grace, pygrace and expeyes
Hi, This is my summary, see below for specific replies to specific points: 1. Grace is not unmaintained, it is maintained in Debian by Nicholas Breen. It also is not abandoned upstream, its latest stable release being from late 2012. 2. As t1lib is superseded and unmaintained, it should be removed from Debian as a library package. 3. As grace is a useful application, it should remain in Debian. To this end, with respect to point #2 above, it could start to use the internal copy of t1lib instead of the external package. 4. As soon as grace is switched to the internal copy, t1lib becomes a convenience library of grace, similar to thousands of other convenience libraries in Debian package. In particular, security concerns should be less pronounced, as grace does not (TTBOMK) run as root, nor does it listen on the network. Basically, the security concerns should be similar to any other piece of C/C++ code in any other graphical application. 5. Nobody gets to tell the grace maintainer at which level the grace package should be maintained, but everybody is welcome to file bugs and patches for specific issues. On Sun, Mar 23, 2014 at 01:17:55PM +, Neil Williams wrote: On Sun, 23 Mar 2014 13:08:14 +0100 Michael Banck mba...@debian.org wrote: On Sun, Mar 23, 2014 at 10:03:53AM +, Neil Williams wrote: On Sat, 22 Mar 2014 20:38:49 -0700 Nicholas Breen nbr...@debian.org wrote: On Sat, Mar 22, 2014 at 04:10:39PM +, Neil Williams wrote: I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. If just getting standalone t1lib out of the archive is the goal, I don't mind incorporating all of the existing t1lib patches into the embedded copy. No. How does that solve the problem of t1lib being abandoned upstream and already superseded by freetype? Why is it a problem in the first place? Software is being rewritten and superseded constantly, this doesn't mean other software using those old libraries are immediately to be sent to the bin. It's not immediate. t1lib has had no upstream changes in Debian since 2008! grace itself has not had upstream changes introduced into Debian since the same time. For some values of 2008 being 2012: |grace (1:5.1.23-1) unstable; urgency=low | | * New upstream release. (Closes: #689532) | | -- Nicholas Breen nbr...@debian.org Wed, 31 Oct 2012 17:09:21 -0700 Abandoned software doesn't need to bit rot forever in Debian. If there is reason to keep it, there is reason for someone to maintain it. Whilst it remains orphaned, it will be considered unmaintained, abandoned and suitable for removal. Which package are you talking about here? Grace is maintained by Nicholas Breen, according to the PTS. I think this is the grace's maintainer's call. But then maybe I am missing part of the conversatio and your motivation to have grace removed. Personally, I don't think it is good to have an embedded copy of a removed package inside a package which remains in the archive. What would be needed is an assurance from the grace maintainer and those who are keen to retain grace in Debian, that the internal t1lib code would be maintained inside grace to a better standard than it has so far been maintained outside grace. Again, that is not your call to make, but the maintainer's. He is apparently willing to maintain the grace package, with or without an internal copy of t1lib. That may be simpler to do if the grace maintainer interested parties adopt t1lib (upstream and in Debian). At that point, the problem with t1lib become manageable again. That would close #637488 and #638760 at the same time. If they want to do this, fine, but it is certainly not necessary for them. As t1lib is superseded, I think it makes more sense to keep its code around just for grace inside the grace source package. This will also discourage other developers from using the t1lib library in their projects. As grace is almost exclusively used to plot locally-supplied numeric data, and is not in any way practical to use in a network setting, it has minimal security risk vs. some other former users of t1lib like php5. The security issues were only one part of this - t1lib has been abandoned and superseded. It is unsupportable, as are packages which rely on it. It is being supported by grace upstream as part of the embedded library, as written elsewhere on this thread. For some values of supported, but I don't see the point in removing grace completely. If you want to get rid of the the t1lib package - fine, but I think using the embedded copy is an acceptable solution for grace. This would need to be declared clearly in the grace package description and maintained as
Bug#638760: Removal of grace, pygrace and expeyes
Dear Evgeny, I strongly back your point of view. As Neil wants a quick solution, I shall develop alternative depedencies for expeyes which currently relies on grace: it will offer the possibility to choose qtiplot. I agree with you, a user which learned to use Xmgrace will grind loads of work happily. Best regards, Georges. Evgeny Stambulchik a écrit : Hello, I'm the [passive] upstream maintainer. Just to make things clear: 1. grace is perfectly happy using its own copy of t1lib. So you can safely remove the t1lib debian package. 2. Yes, perhaps only 0.34% of all users use it. But same can be said about 90% of the entire debian archive (for each package separately, of course). 3. Yes, it is potentially buggy and insecure. But since in 99.9% you use it within the projects you work yourself on, nothing wrong can happen. In the worst case you loose some time. (And in my experience, grace crashes MUCH less frequently than some high-profile softwares which are really exposed to the Internet.) 4. I have no time and intention right now to switch to freetype. For the scope it is currently used in grace, t1lib is adequate. When I come across a bug, I fix it - that's how the bundled t1lib copy got emerged in the first place. Best, Evgeny On 23/03/14 12:01, Neil Williams wrote: On Sun, 23 Mar 2014 11:01:39 +1100 Drew Parsons dpars...@debian.org wrote: Grace is one of the most useful packages in the entire archive. ... for 0.34% of users of the archive, maybe. To me, it is simply an RC buggy package which has had no new development upstream since 2012 and which depends on an obsolete, abandoned library. Unless it can be ported, it will need to be removed alongside t1lib. Those who care about grace need to scratch their own itch and fix it. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. Removing it is necessary, as explained. t1lib has been superseded and packages which used to use it need to migrate. The other packages have already done so, those which fail to do so cannot be supported when the underlying dependency has been abandoned. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: Digital signature
Bug#638760: Removal of grace, pygrace and expeyes
On Sun, Mar 23, 2014 at 10:02 AM, Michael Banck wrote: Hi, This is my summary, see below for specific replies to specific points: 1. Grace is not unmaintained, it is maintained in Debian by Nicholas Breen. It also is not abandoned upstream, its latest stable release being from late 2012. 2. As t1lib is superseded and unmaintained, it should be removed from Debian as a library package. 3. As grace is a useful application, it should remain in Debian. To this end, with respect to point #2 above, it could start to use the internal copy of t1lib instead of the external package. 4. As soon as grace is switched to the internal copy, t1lib becomes a convenience library of grace, similar to thousands of other convenience libraries in Debian package. In particular, security concerns should be less pronounced, as grace does not (TTBOMK) run as root, nor does it listen on the network. Basically, the security concerns should be similar to any other piece of C/C++ code in any other graphical application. Embedded libraries are almost always to be avoided due to numerous reasons listed in the Debian security documentation. You can make the change to internal t1lib, but you should expect an RC bug and removal from testing after some time. That may be a compromise solution. You get to keep grace in unstable, and advanced users that need it can figure out how to fetch it there, and at the same time, the deprecated library is kept out of testing and stable. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
Hi, On Sun, Mar 23, 2014 at 12:47:18PM -0400, Michael Gilbert wrote: On Sun, Mar 23, 2014 at 10:02 AM, Michael Banck wrote: This is my summary, see below for specific replies to specific points: 1. Grace is not unmaintained, it is maintained in Debian by Nicholas Breen. It also is not abandoned upstream, its latest stable release being from late 2012. 2. As t1lib is superseded and unmaintained, it should be removed from Debian as a library package. 3. As grace is a useful application, it should remain in Debian. To this end, with respect to point #2 above, it could start to use the internal copy of t1lib instead of the external package. 4. As soon as grace is switched to the internal copy, t1lib becomes a convenience library of grace, similar to thousands of other convenience libraries in Debian package. In particular, security concerns should be less pronounced, as grace does not (TTBOMK) run as root, nor does it listen on the network. Basically, the security concerns should be similar to any other piece of C/C++ code in any other graphical application. Embedded libraries are almost always to be avoided due to numerous reasons listed in the Debian security documentation. Please explain how this is different to any other convenience library? As soon as the t1lib library package is removed from Debian, it is not an embedded library anymore, just some code. It probably makes sense to link it statically then. You can make the change to internal t1lib, but you should expect an RC bug and removal from testing after some time. Whether or not that situation is RC (I don't think it would be) would be up to the release team or ultimately the tech-ctte I guess. That may be a compromise solution. You get to keep grace in unstable, and advanced users that need it can figure out how to fetch it there, and at the same time, the deprecated library is kept out of testing and stable. I don't see a reason not to ship it in jessie. Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
Hi, IMHO, this discussion went well out of proportions... On 23/03/14 18:47, Michael Gilbert wrote: Embedded libraries are almost always to be avoided due to numerous reasons listed in the Debian security documentation. Right, but these reasons are inapplicable when the external library is removed from the debian archive and as such, is literally inexistent for debian users. From this point on, t1lib is a part of the grace package. Its sources should be treated exactly like the rest of C files under the grace-x.y.z directory. You can make the change to internal t1lib, but you should expect an RC bug and removal from testing after some time. Why then? I mean, anything may happen, but how is this related to the _current_ motion to remove the _t1lib_ package? That may be a compromise solution. You get to keep grace in unstable, and advanced users that need it can figure out how to fetch it there, and at the same time, the deprecated library is kept out of testing and stable. The deprecated library is kept out of testing and stable by removing _its_ _own_ package. It is not installed in /usr/[lib,include]. Just linked statically in a single executable. Best, Evgeny -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On 23/03/14 19:04, Michael Banck wrote: As soon as the t1lib library package is removed from Debian, it is not an embedded library anymore, just some code. It probably makes sense to link it statically then. And this is exactly what is going to happen. When an external t1lib is not found, configure falls back to using the bundled static library. It has been so for many, many years. So all that is needed is removing the explicit dependency on t1lib. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
Grace is one of the most useful packages in the entire archive. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. Drew On Sat, 2014-03-22 at 16:10 +, Neil Williams wrote: I've attached a patch that changes grace to use its embedded t1lib copy. This is not at all ideal since probably most of the t1lib security patches aren't included, but grace is the last package remaining to drop support for t1lib, so it needs a change. Swapping a buggy package for an old embedded buggy package is not a solution. It's not just far from ideal, it is not even worth considering. I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On Sat, Mar 22, 2014 at 8:01 PM, Drew Parsons wrote: Grace is one of the most useful packages in the entire archive. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. That can be fixed by anyone willing to spend the time to update it to use freetype. Removing the package will likely provide an incentive for someone sufficiently skilled and interested to do that, and it will eventually be back. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On Sat, 2014-03-22 at 20:07 -0400, Michael Gilbert wrote: On Sat, Mar 22, 2014 at 8:01 PM, Drew Parsons wrote: Grace is one of the most useful packages in the entire archive. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. That can be fixed by anyone willing to spend the time to update it to use freetype. Removing the package will likely provide an incentive for someone sufficiently skilled and interested to do that, and it will eventually be back. At the core of it, lib/canvas/t1fonts.c would need to be replaced, and Canvas in include/grace/canvasP.h and various client code points would need to be updated to match. Sounds like a worthy candidate for the Google Summer of Code. Drew [... or even better, pay someone to port the entire thing wholesale to Qt] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On Sat, Mar 22, 2014 at 04:10:39PM +, Neil Williams wrote: I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. If just getting standalone t1lib out of the archive is the goal, I don't mind incorporating all of the existing t1lib patches into the embedded copy. As grace is almost exclusively used to plot locally-supplied numeric data, and is not in any way practical to use in a network setting, it has minimal security risk vs. some other former users of t1lib like php5. If getting t1lib in all its forms out of the archive is the goal, then yes, grace would have to be removed. Rewriting it is not practical and there doesn't seem to be anyone with the time + desire + skillset to adopt t1lib. However, there's also no real replacement for grace itself available. -- Nicholas Breen nbr...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
I've attached a patch that changes grace to use its embedded t1lib copy. This is not at all ideal since probably most of the t1lib security patches aren't included, but grace is the last package remaining to drop support for t1lib, so it needs a change. Swapping a buggy package for an old embedded buggy package is not a solution. It's not just far from ideal, it is not even worth considering. I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
