Re: Provide libijs packages as a binary package of Ghostscript?
On 01/25/2011 08:27 PM, Jonas Smedegaard wrote: Another argument for keeping libijs separate: I consider packaging GNU Ghostscript, which seem to have a slightly different development pace and thus might be interesting e.g. for security concerned users, and would also make the recent RC issue of ghostscript less dramatic, as there would be the option of ripping out one of the implementations temporarily, if multiple ones were available to choose from. Yes, I know that this was tried in the past, and I have not yet decided to try it out again, just considering, so far... Please do not remove GPL Ghostscript from Debian. It is the real upstream and so bug fixes and new features get available at first via GPL GS and reach GNU GS only with a delay. I have even upstream commit access to GPL GS and so I can get in my fixes quickly. If Debian switches to only use GNU GS I will not be able to maintain one and the same Ghostscript package for both Debian and Ubuntu. In Ubuntu the use of GPL GS is essentially important to have always the most up-to-date code. Till -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d400c6b.3050...@gmail.com
Re: Provide libijs packages as a binary package of Ghostscript?
On 01/25/2011 09:48 PM, Roger Leigh wrote: Just for the record, I think there should be *one* copy of ijs only. I really don't care whether it's in ijs or gs. However, given that gs is required for ijs to work, and the copy in gs has had some maintenance, I think the gs copy would be the better choice (providing it can be made usable for others). They are probably the effective upstream maintainers of the code in any case given the complete lack of upstream ijs activity for years. [The upstream were the gs maintainers (more or less) in any case.] I agree with that, each piece of source code should go into the distro once, and if possible there should also not be any duplication of binary code. I did try to hack on getting gs to do this back in 2002, but gs was so baroque I couldn't make any headway. If it's easy to get the gs build system to build and link with a shared lib, and generate the .pc file, that would be great. It just needs someone familiar with gs. The GS upstream developers are currently working on the ijs/ subdirectory and its build system, to at least accept an external shared libijs on demand by ./configure option or on absence of the ijs/ directory. I could also ask them to add support for the scenario of building the shared libijs from the code in the ijs/ directory and making Ghostscript using it. (I remember the horror of when gutenprint (then gimpprint) was also embedded wholesale in the gs tree as gdevstp; it was imported regularly from our CVS, and it make it hard to develop since it was so fragile and we had to make sure our Makefiles stayed compatible with the gs tree. IJS was a Godsend since it allowed us to be entirely separate.) IMO the wholesale embedding of stuff in gs is a symptom of wider issues in gs (the number of embedded drivers is horrifying--they should all have been made modular years back, which would prevent stupid stuff like having to have gs linked with X etc.). I have opened student projects in the Google Summer of Code for modularizing the drivers but never found students to actually do that. Especially I would like to see a modularization that one can bolt GS' drivers also on Poppler. Have there been any gs issues related to ijs? AFAICT, they directly copied the IJS sources files straight into their tree, so any issues should be present in both packages. No issues known to me. GS devs copied over IJS code once (years ago), then they did some fixes. No code got copied back to OpenPrinting and Ghostscrit's code got considered the official one. Note that Ghostscript generally includes the source code of all used libraries into the GS tree to make it compilable and debuggable under Windows. Till -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d401078.5090...@gmail.com
Re: Provide libijs packages as a binary package of Ghostscript?
On 01/25/2011 10:04 PM, Jonas Smedegaard wrote: I think perhaps you miss my point: If libijs is maintained for Debian as part of the GPL Ghostscript project, and we also (in the future) maintain GNU Ghostscript, then GNU Ghostscript will need to depend on GPL Ghostscript, making it impossible to ship a release of Debian with only GNU Ghostscript, not GPL Ghostscript. If, on the other hand, Debian maintain libijs as a separate project, then a release of Debian (or a derivative thereof) can choose to ship with GNU Ghostscript and not GPL Ghostscript. The question is not whether upstream development happens as part of GPL Ghostscript or not, but whether we should maintain a library separately which is _usable_ seaparately. AFAIK GNU Ghostscript is a fork of GPL Ghostscript. Does GNU Ghostscript not ship ijs/, too? What are the exact differences between GNU GS and GPL GS? Till -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d406ec4.2030...@gmail.com
Re: Provide libijs packages as a binary package of Ghostscript?
On Wed, Jan 26, 2011 at 07:58:12PM +0100, Till Kamppeter wrote: On 01/25/2011 10:04 PM, Jonas Smedegaard wrote: I think perhaps you miss my point: If libijs is maintained for Debian as part of the GPL Ghostscript project, and we also (in the future) maintain GNU Ghostscript, then GNU Ghostscript will need to depend on GPL Ghostscript, making it impossible to ship a release of Debian with only GNU Ghostscript, not GPL Ghostscript. If, on the other hand, Debian maintain libijs as a separate project, then a release of Debian (or a derivative thereof) can choose to ship with GNU Ghostscript and not GPL Ghostscript. The question is not whether upstream development happens as part of GPL Ghostscript or not, but whether we should maintain a library separately which is _usable_ seaparately. AFAIK GNU Ghostscript is a fork of GPL Ghostscript. Does GNU Ghostscript not ship ijs/, too? Upstream they probably do, yes. A Debian packaging should equally have it stripped (or ignored) and use a separately packaged libijs, to avoid code duplication. And, as explained above, to not essentially have one Ghostscript depend on another thereby loosing a benefit of maintaining both. What are the exact differences between GNU GS and GPL GS? Don't know. Just noticed somewhere bugfixes trickling into the GNU one in a different pace than the GPL one. I am quite annoyed learning (from you) that GPL GS coordinates releases with Ubuntu instead of distro-agnosticly release early, release often! Bug-fixes are hanging unreleased for a _very_ long time. But really this shouldn't be about whether GNU GS is relevant for Debian to package in particular, but about the principle of keeping libijs separate. Another use case is _users_ of Debian wanting to compile GNU GS themselves but rely on most possible underlying libraries security-maintained by Debian. - 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
Re: Provide libijs packages as a binary package of Ghostscript?
On Mon, Jan 24, 2011 at 08:47:07PM +0100, Jonas Smedegaard wrote: Hi Till (and others), I took the liberty of moving this conversation to the Debian Printing Team and cc ijs package maintainer. On Mon, Jan 24, 2011 at 08:12:31PM +0100, Till Kamppeter wrote: as written on http://www.openprinting.org/download/ijs/ the current head of development of the IJS code is in Ghostscript and not on OpenPrinting. So to keep the binary packages - libijs-0.35 - libijs-dev maintained with the up-to-date source code I suggest to remove the ijs source package from Debian and build the IJS library using the ijs/ directory of Ghostscript (naturally then not removing it from Ghostscript when repackaging the source tarball). See also http://bugs.ghostscript.com/show_bug.cgi?id=691904 WDYT? I dislike treating Ghostscript as source of multiple libraries! I think that a) ijs package should cherry-pick from ghostscript sources (manually, from upstream tarballs and/or VCS), and b) ijs package maintainers (or anyone, really - perhaps yourself?) verify if current ijs upstream truly is dead or have sane reason to not adopt what is currently shipped with ghostscript. When those options are tried, we can discuss if perhaps we shoulf try convince Ghostscript developers to release their library as separate tarballs. As a related note, I recommend ijs package maintainer to join the Debian Printing Team to ease coordination like this. :-) I was the original packager and maintainer of ijs, and I was also involved with upstream when it was created, so I might be able to provide some insight here. I was also the one who added autotools and shared library support upstream. IJS implements a transport protocol between a client (ghostscript) and a server (printer driver) to allow ghostscript to use drivers not hard-coded in the ghostscript sources. This allows it to use out-of-tree drivers such as gutenprint. Early on, ghostscript decided to import the sources directly into their tree rather than linking with the actual libijs library; I forget the exact rationale for this. Initially the ijs sources were not usable as a real library--I had to make it into a shared library since initially it was only usable by embedding. IJS is basically complete and will not change: the protocol is defined and there's no reason to touch the code bar bugfixing, and that's been done. So ghostscript doesn't need to continually track new releases. However, this is a *client-server* model. ghostscript is the client; anything else could be a server. Unless the server also does the embedding of the ijs sources, it will need to link with libijs; it can't use the internal ghostscript copy, since ghostscript doesn't build it as a library--it's just linked in. My take on this is that there are these solutions: 1) ghostscript removes the embedded ijs copy and links with libijs Any fixes in the ghostscript copy should be applied to libijs. 2) ijs is removed ghostscript's copy will be the canonical source, and ghostscript will build this as a shared library and link with it; other programs will be able to use it. I would ordinarily prefer (1), but given that ijs is /de facto/ specific to ghostscript (there are no other ijs clients to my knowledge) I can't see a problem with it being provided by ghostscript, so long as it makes a proper shared library and provides the same pkg-config support etc. This is basically to ensure it's as usable by third parties as the existing libijs (which I made usable so that this was possible). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Provide libijs packages as a binary package of Ghostscript?
On Tue, Jan 25, 2011 at 08:27:38PM +0100, Jonas Smedegaard wrote: On Tue, Jan 25, 2011 at 06:59:08PM +, Roger Leigh wrote: I was the original packager and maintainer of ijs, and I was also involved with upstream when it was created, so I might be able to provide some insight here. I was also the one who added autotools and shared library support upstream. IJS implements a transport protocol between a client (ghostscript) and a server (printer driver) to allow ghostscript to use drivers not hard-coded in the ghostscript sources. This allows it to use out-of-tree drivers such as gutenprint. Early on, ghostscript decided to import the sources directly into their tree rather than linking with the actual libijs library; I forget the exact rationale for this. Initially the ijs sources were not usable as a real library--I had to make it into a shared library since initially it was only usable by embedding. IJS is basically complete and will not change: the protocol is defined and there's no reason to touch the code bar bugfixing, and that's been done. So ghostscript doesn't need to continually track new releases. However, this is a *client-server* model. ghostscript is the client; anything else could be a server. Unless the server also does the embedding of the ijs sources, it will need to link with libijs; it can't use the internal ghostscript copy, since ghostscript doesn't build it as a library--it's just linked in. My take on this is that there are these solutions: 1) ghostscript removes the embedded ijs copy and links with libijs Any fixes in the ghostscript copy should be applied to libijs. 2) ijs is removed ghostscript's copy will be the canonical source, and ghostscript will build this as a shared library and link with it; other programs will be able to use it. I would ordinarily prefer (1), but given that ijs is /de facto/ specific to ghostscript (there are no other ijs clients to my knowledge) I can't see a problem with it being provided by ghostscript, so long as it makes a proper shared library and provides the same pkg-config support etc. This is basically to ensure it's as usable by third parties as the existing libijs (which I made usable so that this was possible). Thanks for the insight! Just for the record, I think there should be *one* copy of ijs only. I really don't care whether it's in ijs or gs. However, given that gs is required for ijs to work, and the copy in gs has had some maintenance, I think the gs copy would be the better choice (providing it can be made usable for others). They are probably the effective upstream maintainers of the code in any case given the complete lack of upstream ijs activity for years. [The upstream were the gs maintainers (more or less) in any case.] I did try to hack on getting gs to do this back in 2002, but gs was so baroque I couldn't make any headway. If it's easy to get the gs build system to build and link with a shared lib, and generate the .pc file, that would be great. It just needs someone familiar with gs. (I remember the horror of when gutenprint (then gimpprint) was also embedded wholesale in the gs tree as gdevstp; it was imported regularly from our CVS, and it make it hard to develop since it was so fragile and we had to make sure our Makefiles stayed compatible with the gs tree. IJS was a Godsend since it allowed us to be entirely separate.) IMO the wholesale embedding of stuff in gs is a symptom of wider issues in gs (the number of embedded drivers is horrifying--they should all have been made modular years back, which would prevent stupid stuff like having to have gs linked with X etc.). Another argument for keeping libijs separate: I consider packaging GNU Ghostscript, which seem to have a slightly different development pace and thus might be interesting e.g. for security concerned users, and would also make the recent RC issue of ghostscript less dramatic, as there would be the option of ripping out one of the implementations temporarily, if multiple ones were available to choose from. Have there been any gs issues related to ijs? AFAICT, they directly copied the IJS sources files straight into their tree, so any issues should be present in both packages. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Provide libijs packages as a binary package of Ghostscript?
Hi Till (and others), I took the liberty of moving this conversation to the Debian Printing Team and cc ijs package maintainer. On Mon, Jan 24, 2011 at 08:12:31PM +0100, Till Kamppeter wrote: as written on http://www.openprinting.org/download/ijs/ the current head of development of the IJS code is in Ghostscript and not on OpenPrinting. So to keep the binary packages - libijs-0.35 - libijs-dev maintained with the up-to-date source code I suggest to remove the ijs source package from Debian and build the IJS library using the ijs/ directory of Ghostscript (naturally then not removing it from Ghostscript when repackaging the source tarball). See also http://bugs.ghostscript.com/show_bug.cgi?id=691904 WDYT? I dislike treating Ghostscript as source of multiple libraries! I think that a) ijs package should cherry-pick from ghostscript sources (manually, from upstream tarballs and/or VCS), and b) ijs package maintainers (or anyone, really - perhaps yourself?) verify if current ijs upstream truly is dead or have sane reason to not adopt what is currently shipped with ghostscript. When those options are tried, we can discuss if perhaps we shoulf try convince Ghostscript developers to release their library as separate tarballs. As a related note, I recommend ijs package maintainer to join the Debian Printing Team to ease coordination like this. :-) If this email conversation itself does not cause action from ijs package maintainers, I suggest filing a bugreport against ijs to formally raise awareness on those sources supposedly lacking behind. Ideally with those same recommendations as I suggest above, but if you do the bugfiling then obviously you get to influence in what direction you prefer ;-) Kind regards, - 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
Re: Provide libijs packages as a binary package of Ghostscript?
On 01/24/2011 08:47 PM, Jonas Smedegaard wrote: Hi Till (and others), I took the liberty of moving this conversation to the Debian Printing Team and cc ijs package maintainer. OK, good idea. I dislike treating Ghostscript as source of multiple libraries! I prefer having each upstream source tarball which exists entering the distribution only once. With this principle replacing the upstream tarball by a newer version is easy. Replaced at this one point where it enters it is replaced for the whole distro. It cannot happen that one forgets the other places then. If the tarball contains the source for several binary packages, it should generate all these binaries as separate binary packages. If a certain piece of source code exists more than once upstream, it must be checked carefully, which version is the one which is actively maintained. Only this version should be used. I think that a) ijs package should cherry-pick from ghostscript sources (manually, from upstream tarballs and/or VCS), and b) ijs package maintainers (or anyone, really - perhaps yourself?) verify if current ijs upstream truly is dead or have sane reason to not adopt what is currently shipped with ghostscript. I am the maintainer of the OpenPrinting web site and no one asked for write access to the IJS page when the site got moved to a new server mid-2006. So from then on it is definitely not maintained any more on the OpenPrinting web site. The Ghostscript maintainers did small changes (bug fixes, make it build under Windows, ...). As only they do maintenance work on it I am fine with the maintained source code of IJS being the ijs/ directory of Ghostscript. The IJS web page on OpenPrinting clearly tells that the officially maintained source code is in Ghostscript. When those options are tried, we can discuss if perhaps we shoulf try convince Ghostscript developers to release their library as separate tarballs. So please ask them via IRC, channel #ghostscript on Freenode or report a bug/feature request (product: Ghostscript, component: printer driver) on http://bugs.ghostscript.com/. If IJS does not get separated my suggesstion for best maintainability is to let the libijs* packages being binary packages of the ghostscript source package. As a related note, I recommend ijs package maintainer to join the Debian Printing Team to ease coordination like this. :-) If this email conversation itself does not cause action from ijs package maintainers, I suggest filing a bugreport against ijs to formally raise awareness on those sources supposedly lacking behind. Ideally with those same recommendations as I suggest above, but if you do the bugfiling then obviously you get to influence in what direction you prefer ;-) OK. Till -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3de126.7020...@gmail.com
Re: Provide libijs packages as a binary package of Ghostscript?
On Mon, Jan 24, 2011 at 09:29:26PM +0100, Till Kamppeter wrote: On 01/24/2011 08:47 PM, Jonas Smedegaard wrote: I think that a) ijs package should cherry-pick from ghostscript sources (manually, from upstream tarballs and/or VCS), and b) ijs package maintainers (or anyone, really - perhaps yourself?) verify if current ijs upstream truly is dead or have sane reason to not adopt what is currently shipped with ghostscript. I am the maintainer of the OpenPrinting web site and no one asked for write access to the IJS page when the site got moved to a new server mid-2006. So from then on it is definitely not maintained any more on the OpenPrinting web site. Heh. I am convinced! :-) The Ghostscript maintainers did small changes (bug fixes, make it build under Windows, ...). As only they do maintenance work on it I am fine with the maintained source code of IJS being the ijs/ directory of Ghostscript. The IJS web page on OpenPrinting clearly tells that the officially maintained source code is in Ghostscript. When those options are tried, we can discuss if perhaps we shoulf try convince Ghostscript developers to release their library as separate tarballs. So please ask them via IRC, channel #ghostscript on Freenode or report a bug/feature request (product: Ghostscript, component: printer driver) on http://bugs.ghostscript.com/. If IJS does not get separated my suggesstion for best maintainability is to let the libijs* packages being binary packages of the ghostscript source package. I'd let Debian ijs package maintainer do that - if in agreement that this is a sensible approach. We (as in ghostscript maintainer and/or Printing Team) cannot hijack ijs package, so need to wait for some response from ijs package maintainer. As a related note, I recommend ijs package maintainer to join the Debian Printing Team to ease coordination like this. :-) If this email conversation itself does not cause action from ijs package maintainers, I suggest filing a bugreport against ijs to formally raise awareness on those sources supposedly lacking behind. Ideally with those same recommendations as I suggest above, but if you do the bugfiling then obviously you get to influence in what direction you prefer ;-) OK. Filing a bugreport also helps in resolving if perhaps ijs package maintainer might be MIA... - 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
Re: Provide libijs packages as a binary package of Ghostscript?
On 01/24/2011 10:11 PM, Jonas Smedegaard wrote: Filing a bugreport also helps in resolving if perhaps ijs package maintainer might be MIA... According to http://packages.debian.org/changelogs/pool/main/i/ijs/ijs_0.35-7/changelog last change on package in April 2009, last change on active code of the package in Feb 2004 and current maintainer is Bradley Smith (bradsmith at debian dot org). Till -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d3ded3b.1010...@gmail.com
Re: Provide libijs packages as a binary package of Ghostscript?
On Mon, Jan 24, 2011 at 10:20:59PM +0100, Till Kamppeter wrote: On 01/24/2011 10:11 PM, Jonas Smedegaard wrote: Filing a bugreport also helps in resolving if perhaps ijs package maintainer might be MIA... According to http://packages.debian.org/changelogs/pool/main/i/ijs/ijs_0.35-7/changelog last change on package in April 2009, last change on active code of the package in Feb 2004 and current maintainer is Bradley Smith (bradsmith at debian dot org). Yes. I noticed that. It is legal for a package to not need changes for a very very long time. Someone have to formally request a change to properly resolve if silence is due to maintainer being MIA or simply no need for maintainance. NB! Putting back ijs package as cc. - 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
