Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
Also thank you very much for accepting my changes. Now the differences between the Ubuntu (Natty, 11.04) package and the Debian package are minimal: 1. The Ubuntu package has the hook for the automatic bug reporting system Apport. 2. In the Ubuntu package the menu entry for the paper-out resetter for the HP LaserJet 1018/1020 is suppressed, as it is very hardware-specific. Till On 02/19/2011 08:32 PM, Luca Capello wrote: Hi there! Till, a big THANK YOU for the detailed explanations, I really appreciated. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
Hi Till! I removed all Cc:s except the BTS, they are now useless. On Thu, 24 Feb 2011 10:32:27 +0100, Till Kamppeter wrote: Also thank you very much for accepting my changes. Frankly speaking, it was my pleasure, you always took the time to explain in details all your changes, something I really appreciate. Now the differences between the Ubuntu (Natty, 11.04) package and the Debian package are minimal: 1. The Ubuntu package has the hook for the automatic bug reporting system Apport. On a standard Debian 6.0.0/squeeze there is already another Apport file: hplip-data:/usr/share/apport/package-hooks/source_hplip.py While I would prefer not to have non-Debian files on my Debian, I do not have any strong opinion on this and it seems this situation is perfectly fine, at least debootstrap contains a lot of scripts for Ubuntu distributions (/usr/share/debootstrap/scripts/). So I would say you should go on and include it even in the Debian package. This will also strengthen the collaboration between the two distributions. 2. In the Ubuntu package the menu entry for the paper-out resetter for the HP LaserJet 1018/1020 is suppressed, as it is very hardware-specific. While I do not agree on that, you should be aware that at least on Dian the GNOME team decided to unconditionally do that, so your action is superfluous: http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=225 Thx, bye, Gismo / Luca pgpPlr1EWvsmK.pgp Description: PGP signature
Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
OK. Then take the Apport hook into the Debian package and we keep foo2zjs identical on Debian and Ubuntu. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
Le Thursday 24 February 2011 13:12:13 Till Kamppeter, vous avez écrit : OK. Then take the Apport hook into the Debian package and we keep foo2zjs identical on Debian and Ubuntu. Till If this is done (and I think it's desirable for Ubuntu), please do it in a Distribution-dependent way, see e.g. the foomatic-filters debian/rules: derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu echo yes) || echo no) (…) override_dh_install: dh_install ifeq ($(derives_from_ubuntu),yes) install -D -m 644 debian/ubuntu/apport-hook.py $(CURDIR)/debian/foomatic-filters/usr/share/apport/package-hooks/source_foomatic-filters.py endif This way you have one source package, but the binary package gets different contents depending on the distribution. Cheers, OdyX -- Didier Raboud, proud Debian Developer. CH-1020 Renens o...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
Hi there! Till, a big THANK YOU for the detailed explanations, I really appreciated. On Wed, 16 Feb 2011 00:23:47 +0100, Till Kamppeter wrote: On 11/05/2010 04:10 AM, Luca Capello wrote: On Wed, 13 Oct 2010 02:21:35 +0200, Luca Capello wrote: On Mon, 27 Sep 2010 23:16:49 +0200, Till Kamppeter wrote: On 09/27/2010 06:53 PM, Luca Capello wrote: 4) I am not sure debian/local/ is the right place for non-upstream files, but I should admit that this is the first time I heard about it and I can not find any documentation about that. Nevermind, I have added the two non-upstream PPDs. BTW, conceptually speaking, Ubuntu debian/rules misses the command to compress these two files, given that this action is hidden in the 'Add *cupsFilter line to accept PDF input data to the PPDs' block. [...] This makes the PPD files allow PDF as input format. This way the print queues integrate with the PDF-based printing workflow which is implemented in Debian and Ubuntu. [...] https://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat Committed: http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=257 I have seen may packages which use debian/local/ to add non-upstream files. Sorry if I was not clear, but debian/local/ seems perfectly fine with me, the only caveat was that I had never heard about it before :-) Anyway, we do not need it anymore, the latest snapshot packaged (see below) includes the two files above. 5) - debian/foo2zjs.postinst: Automatically update the PPD files for existing queues to the versions supplied with this package. - debian/control: Add dependency on cups and cups-client to ensure that automatic update of the PPDs of existing print queues works. [...] Therefore I let the package do the dirty work as doing a really complete update by letting the postinst script updating the PPDs of the already configured queues in /etc/cups/ppd/. The only configuration in these files are the default settings (lines starting with *Default...), The rest of the files are printer-specific and no user configuration. The automatic update is done with CUPS' lpadmin command line utility which preserves the default settings. This way the user has always the correct PPD for his driver (works on both up- and downdate of the package) and his default settings do not get lost. Printing will just work for him. That is what I wanted to read, thank you, committed: http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=258 http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=259 BTW, technically speaking I would be against the dependency on cups and cups-client for the postinst to work, given that there is no problem if the existing queues are not updated. OTOH, foo2zjs does not work at all without cups, so this is harmless and I added the dependencies as well. NB, I re-ordered your quoted text below. 10) - debian/rules: Add /etc/papersize support, and modify all /usr/bin/foo2*-wrapper scripts to handle custom page sizes correctly in the PDF-based printing workflow. [...] - Support for the PDF printing workflow: [...] o Let wrapper scripts read custom page sizes also from the command line and not only from embedded PostScript commands. [...] There are awkward foo2...-wrapper scripts, all identical except a few lines. [...] Therefore I use Perl magic in the debian/rules file to do these identical changes on all the scripts. [...] 1. Add /etc/papersize support: This change on the foo2...-wrapper scripts makes the default page size being taken from /etc/papersize, like all programs which use libpaper do, too. This way one has a reasonable default paper size and not Letter which is used only in two countries on the world. Committed: http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=260 http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=261 FTR, I erroneously thought CUPS was also at fault here (i.e. it ignored /etc/papersize), but it seems I was wrong: http://bugs.debian.org/88597 However, I guess that the best option would be to support LC_PAPER, given that AFAIK libpaper (thus /etc/papersize) is still a debianism while LC_PAPER is POSIX: http://bugs.debian.org/376350 Anyway, this bug is not the place for such discussions ;-) Also doing the same change on all PPD files is rather awkward by a patch and I do also this by Perl Magic in the debian/rules file. You are right, but to track it down I added a fake patch: http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=262 I hope everything is clear now. Sure, but I still have a small question, since there is a debian/changelog entry for which I can not find the corresponding modifications: * debian/foo2zjs.postinst: Migrate driver name foo2zjs to foo2zjs-z1 and foo2zjs-z2. Is this something you have planned but not deployed yet? Finally, some good news ;-)
Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
On 11/05/2010 04:10 AM, Luca Capello wrote: Hi there! On Wed, 13 Oct 2010 02:21:35 +0200, Luca Capello wrote: On Mon, 27 Sep 2010 23:16:49 +0200, Till Kamppeter wrote: On 09/27/2010 06:53 PM, Luca Capello wrote: 4) I am not sure debian/local/ is the right place for non-upstream files, but I should admit that this is the first time I heard about it and I can not find any documentation about that. Nevermind, I have added the two non-upstream PPDs. BTW, conceptually speaking, Ubuntu debian/rules misses the command to compress these two files, given that this action is hidden in the 'Add *cupsFilter line to accept PDF input data to the PPDs' block. Please go ahead and correct also this. I will overtake the version with your corrections to Ubuntu. Given that I still have not understood what the 'Add *cupsFilter line...' does, no corrections on this matter have been made yet. Still valid. This makes the PPD files allow PDF as input format. This way the print queues integrate with the PDF-based printing workflow which is implemented in Debian and Ubuntu. PDF-based printing workflow means that applications send PDF (and not PostScript any more) to CUPS when the user prints his document. CUPS uses PDF as standard file format. Everything coming in which is not PDF (like PostScript output of legacy applications) is turned to PDF at first, then a pdftopdf filter does rearrangement of the pages (if the user selected N-up, reverse order, selected pages, ...), and after that PDF is sent to the driver. See https://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat I have seen may packages which use debian/local/ to add non-upstream files. 5) - debian/foo2zjs.postinst: Automatically update the PPD files for existing queues to the versions supplied with this package. - debian/control: Add dependency on cups and cups-client to ensure that automatic update of the PPDs of existing print queues works. I do not understand the purpose of this action, but I should admit that I am not a CUPS expert and I do not know how other drivers behave. However, given that in Debian the PPDs are configuration files (see http://bugs.debian.org/549673), I would expect dpkg to prompt for any modification, is it so in this case? Still valid. Often the driver has changes which require also changes in the PPD files, for example if options are added or additional settings for an option. If you simply update the package, the driver executables get replaced by the new version and also the PPD files under /usr/share/ppd/, but not the PPD files of already existing print queues in /etc/cups/ppd/. Rick Richardson, the upstream author of foo2zjs simply tells in his ChangeLog to remove and recreate the print queues. Typical distro users neither read the upstream ChangeLog of a package, nor do they not know that their queues need to get manually recreated to make the update complete. They even often do not know that the foo2zjs package is their printer driver. Therefore I let the package do the dirty work as doing a really complete update by letting the postinst script updating the PPDs of the already configured queues in /etc/cups/ppd/. The only configuration in these files are the default settings (lines starting with *Default...), The rest of the files are printer-specific and no user configuration. The automatic update is done with CUPS' lpadmin command line utility which preserves the default settings. This way the user has always the correct PPD for his driver (works on both up- and downdate of the package) and his default settings do not get lost. Printing will just work for him. 10) - debian/rules: Add /etc/papersize support, and modify all /usr/bin/foo2*-wrapper scripts to handle custom page sizes correctly in the PDF-based printing workflow. - debian/rules: Add *cupsFilter line to accept PDF input data to the PPDs. - Support for the PDF printing workflow: o *cupsFilter: lines for PDF input in the PPDs o Let wrapper scripts read custom page sizes also from the command line and not only from embedded PostScript commands. I do not understand these modifications, would you mind explaining them, please? I do not feel comfortable in applying something I do not understand, sorry... Still valid. There are awkward foo2...-wrapper scripts, all identical except a few lines. Why did Rick not make one file with function definitions, source it into all the foo2...-wrapper scripts and use the functions? This way it is awkward to make patches doing the same change in each of the scripts. Especially more or less once a year (every second Ubuntu release) there is a new driver with a new foo2...-wrapper script in the package. Easy to overlook when having patches. Therefore I use Perl magic in the debian/rules
Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
Hi there! On Wed, 13 Oct 2010 02:21:35 +0200, Luca Capello wrote: On Mon, 27 Sep 2010 23:16:49 +0200, Till Kamppeter wrote: On 09/27/2010 06:53 PM, Luca Capello wrote: 4) I am not sure debian/local/ is the right place for non-upstream files, but I should admit that this is the first time I heard about it and I can not find any documentation about that. Nevermind, I have added the two non-upstream PPDs. BTW, conceptually speaking, Ubuntu debian/rules misses the command to compress these two files, given that this action is hidden in the 'Add *cupsFilter line to accept PDF input data to the PPDs' block. Please go ahead and correct also this. I will overtake the version with your corrections to Ubuntu. Given that I still have not understood what the 'Add *cupsFilter line...' does, no corrections on this matter have been made yet. Still valid. 5) - debian/foo2zjs.postinst: Automatically update the PPD files for existing queues to the versions supplied with this package. - debian/control: Add dependency on cups and cups-client to ensure that automatic update of the PPDs of existing print queues works. I do not understand the purpose of this action, but I should admit that I am not a CUPS expert and I do not know how other drivers behave. However, given that in Debian the PPDs are configuration files (see http://bugs.debian.org/549673), I would expect dpkg to prompt for any modification, is it so in this case? Still valid. 10) - debian/rules: Add /etc/papersize support, and modify all /usr/bin/foo2*-wrapper scripts to handle custom page sizes correctly in the PDF-based printing workflow. - debian/rules: Add *cupsFilter line to accept PDF input data to the PPDs. - Support for the PDF printing workflow: o *cupsFilter: lines for PDF input in the PPDs o Let wrapper scripts read custom page sizes also from the command line and not only from embedded PostScript commands. I do not understand these modifications, would you mind explaining them, please? I do not feel comfortable in applying something I do not understand, sorry... Still valid. In the meantime (yeah, as usual a bit slow), I continued importing the remaining Ubuntu changes: 11) wait for 3 seconds when loading firmware http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=241 12) upstream 'getweb' now installs ICM files into the directories of the correct drivers (I slightly modified Till's patch) http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=244 This could also fix http://bugs.debian.org/580690. As I wrote in my first reply, my HP Color LaserJet 1500L seems to be broken, thus I can not test the new package version, thus i386 and amd64 packages to be tested are available at: http://people.debian.org/~gismo/tmp/ New packages available at the link above! Thx, bye, Gismo / Luca pgpSz02WIhbHg.pgp Description: PGP signature
Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
Hi there! Steve, I again cc:ed you since I have implemented your last change from #558978, consider this as a simple notification (read below). On Mon, 27 Sep 2010 23:16:49 +0200, Till Kamppeter wrote: On 09/27/2010 06:53 PM, Luca Capello wrote: I have some concerns about the Ubuntu package, here the first of them, I will continue on another email as far as the integration progresses. 1) I do not understand why from version 20100210-0ubuntu1 the debian/changelog contains the following: [...] Sorry, the README.Debian did not tell which files exactly were removed and I did not search through the debian/changelog. So I assumed that only these *.icm were offending. The new original tarball is now in the SVN repository: http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=233 - remove binary file c5200mono.prn [...] - remove crd/qpdl/CLP*, because copyright is unclear [...] So let us use a common source tarball again, with the files mentioned by you here removed. Please prepare the package, I will merge that into Ubuntu after the Maverick release. Thank you. 2) I do not understand why some patches have been merged, like * debian/patches/60-getweb.in.dpatch, debian/patches/80-getweb.in.dpatch: merged 80-getweb.in.dpatch into 60-getweb.in.dpatch. They fixes two different things, and they must be separated. I thought to better have all for getweb in one patch. Feel free to separate out again this one bashism fix. I will overtake your change then when I make my first foo2zjs package after the Maverick release. I did leave them separated, so everything was already OK. 3) directory should be created through debian/$PKG.dirs and not by hand in debian/rules (see /usr/lib/cups/filter/). [...] While the best option seems thus to fix it in debian/rules, we should use dh_link and not ln. Please change this appropriately. Already done ;-) 4) I am not sure debian/local/ is the right place for non-upstream files, but I should admit that this is the first time I heard about it and I can not find any documentation about that. Nevermind, I have added the two non-upstream PPDs. BTW, conceptually speaking, Ubuntu debian/rules misses the command to compress these two files, given that this action is hidden in the 'Add *cupsFilter line to accept PDF input data to the PPDs' block. Please go ahead and correct also this. I will overtake the version with your corrections to Ubuntu. Given that I still have not understood what the 'Add *cupsFilter line...' does, no corrections on this matter have been made yet. Going on with the Ubuntu changes since version 20090908dfsg-1ubuntu1 (Ubuntu lucid): 5) - debian/foo2zjs.postinst: Automatically update the PPD files for existing queues to the versions supplied with this package. - debian/control: Add dependency on cups and cups-client to ensure that automatic update of the PPDs of existing print queues works. I do not understand the purpose of this action, but I should admit that I am not a CUPS expert and I do not know how other drivers behave. However, given that in Debian the PPDs are configuration files (see http://bugs.debian.org/549673), I would expect dpkg to prompt for any modification, is it so in this case? 6) - debian/foo2zjs.preinst: handle moving 85-hplj10xx.rules from /etc/udev/rules.d to /lib/udev/rules.d, needed for upgrades from hardy. We do not need this, since version 20090908dfsg-2 we install the udev rules file directly in /lib/udev/rules.d/85-hplj10xx.rules. About the udev rules file, as I explained earlier, I do not like the idea of carrying a separate file instead of patching upstream one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558978#36 With the merge of the new upstream and the Ubuntu versions, I have lost some of the fixes submitted in the bug report above, restored: http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=238 And finally, given that the new upstream version adds support for the HP LaserJet P1505n, I added it to the udev rules file: http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=239 7) - debian/control, debian/rules: Do not include msexpand, as it is already in the mscompress package. Add a dependency on mscompress instead. https://bugs.launchpad.net/ubuntu/+source/foo2zjs/+bug/92216 First, msexpand is not present in the upstream COPYING file, but since we ship it in the sources, I added it to the debian/copyright: http://svn.debian.org/viewsvn/foo2zjs?view=revrevision=236 Second, the foo2zjs's msexpand is a Perl script and has nothing to do with the one from the mscompress package. Nevertheless, I tried to understand why msexpand was in the binary package, at least for Debian it was never included, given that its only usage is in the getweb.in script, which actually never calls
Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
Hi Luca, On Mon, Sep 27, 2010 at 06:53:54PM +0200, Luca Capello wrote: Cc:ing Didier, the Ubuntu foo2zjs maintainers and the debian-printing@ mailing list, if you keep the bug report cc:ed, no need to cc: me. I am not a maintainer of the Ubuntu foo2zjs package in Ubuntu. To the extent that packages have maintainers in Ubuntu, for foo2zjs that would be Till, who should speak for himself regarding the package changes. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#594322: [Foo2zjs-maintainer] Bug#594322: foo2zjs: Please upgrade to more recent version for Squeeze.
On 09/27/2010 06:53 PM, Luca Capello wrote: I have some concerns about the Ubuntu package, here the first of them, I will continue on another email as far as the integration progresses. 1) I do not understand why from version 20100210-0ubuntu1 the debian/changelog contains the following: * README.Debian: Updated completely outdated content. We are using the complete original source code again for longer time as there are no binary-only executables and no *.icm files any more in the source tarball. I am sorry but I do not understand why the complete original source code is now DFSG, while nothing changed WRT the files we previously deleted, which from the debian/changelog are: Sorry, the README.Debian did not tell which files exactly were removed and I did not search through the debian/changelog. So I assumed that only these *.icm were offending. - remove binary file c5200mono.prn [...] - remove crd/qpdl/CLP*, because copyright is unclear [...] So let us use a common source tarball again, with the files mentioned by you here removed. Please prepare the package, I will merge that into Ubuntu after the Maverick release. 2) I do not understand why some patches have been merged, like * debian/patches/60-getweb.in.dpatch, debian/patches/80-getweb.in.dpatch: merged 80-getweb.in.dpatch into 60-getweb.in.dpatch. They fixes two different things, and they must be separated. I thought to better have all for getweb in one patch. Feel free to separate out again this one bashism fix. I will overtake your change then when I make my first foo2zjs package after the Maverick release. 3) directory should be created through debian/$PKG.dirs and not by hand in debian/rules (see /usr/lib/cups/filter/). Always about the same issue, the link created by upstream's Makefile is wrong, given it is not a relative one. The correct fix would be to patch upstream's Makefile, but this can be quite tedious especially if upstream changes something. While the best option seems thus to fix it in debian/rules, we should use dh_link and not ln. Please change this appropriately. 4) I am not sure debian/local/ is the right place for non-upstream files, but I should admit that this is the first time I heard about it and I can not find any documentation about that. Nevermind, I have added the two non-upstream PPDs. BTW, conceptually speaking, Ubuntu debian/rules misses the command to compress these two files, given that this action is hidden in the 'Add *cupsFilter line to accept PDF input data to the PPDs' block. Please go ahead and correct also this. I will overtake the version with your corrections to Ubuntu. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
