Bug#411167: ITP: splix -- Splix - SPL2/SPLc Samsung Printer Driver for CUPS
Jeroen van Wolffelaar wrote: owner 411167 ! thanks On Fri, Feb 16, 2007 at 04:14:02PM -0300, Carlos Pasqualini wrote: Package: wnpp Severity: wishlist Owner: Carlos Pasqualini [EMAIL PROTECTED] * Package name: splix Version : 1.0.1-1 Upstream Author : Aurélien Croc [EMAIL PROTECTED] * URL : http://splix.ap2c.org/ * License : GPLv2 Programming Lang: C Description : Splix - SPL2/SPLc Samsung Printer Driver for CUPS SpliX is a set of CUPS printer drivers for SPL (Samsung Printer Language) printers. If you have a such printer, you need to install and use SpliX. Moreover you will find documentation about this proprietary language on the splix website at http://splix.ap2c.org/. I plan to upload splix to Debian based on the Ubuntu package. If either you or the Ubuntu maintainer would like to help out (I can sponsor), please drop me a line, and that's possible. Till, if you want to maintain the package in Debian also, that's also fine by me, it's probably even the easiest way (if you're willing to maintain the package in Debian). Thanks for your interest and help! --Jeroen I think we do the following: The SpliX packages in Debian and Ubuntu should be functionally equal (I did not do anything specific to Ubuntu in my SpliX package). So simply when I put a new SpliX package into Ubuntu, add a debian/changelog entry to it and rebuild for Debian. Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344351: Include libgs.so in Debian
I have packaged GPL Ghostscript 8.60 (SVN snapshot of ESP/GPL Ghostscript merger) for Ubuntu now with separated libgs and also libgs-dev package. I have informed Masayuki Hatta, Ghostscript maintainer of Debian, about it and agreed with him on ghostscript as package name. The Ubuntu source and binary packages are now available at: http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/ghostscript/ I suggest these also for Debian to get once the libgs and second the merger of (the now discontinued) ESP Ghostscript. Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482735: Fwd: [Pkg-hpijs-devel] Bug#482735: hplip should depend on python-qt3
We should also inform the upstream maintainers. I have CCed them to this e-mail. David, Don, can you check this Qt3/Qt4 issue? Thanks. Till Mark Purcell wrote: Dear python-qt4 dudes, I'm the hplip maintainer and I'm having an issue with the transition of hplip from python-qt3 to python-qt4, and need some assistance as I'm not that up to speed with python. In short hplip should now be using python-qt4, but for some reason it still calls some elements of python-qt3 as well as python-qt4. What have I done wrong? Mark -- Forwarded Message -- Subject: [Pkg-hpijs-devel] Bug#482735: hplip should depend on python-qt3 Date: Sun, 25 May 2008 From: Nikos Asimakis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Package: hplip Version: 2.8.4-1 When I try to launch /usr/bin/hp-toolbox (included in hplip) the program doesn't start and the following get's printed in the terminal: HP Linux Imaging and Printing System (ver. 2.8.4) HP Device Manager ver. 13.1 Copyright (c) 2001-8 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. error: PyQt not installed. GUI not available. Exiting. warning: Qt/PyQt initialization failed. error: hp-toolbox requires GUI support. Exiting. Likewise when I try to launch HPLIP Fax Utility (sh -c 'STARTED_FROM_MENU=yes /usr/bin/hp-sendfax') a window appears which informs me I should install python-qt3 After installing python-qt3 manually the problem is resolved. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=el_GR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hplip depends on: ii adduser 3.107 add and remove users and groups ii coreutils6.10-3 The GNU core utilities ii cupsys 1.3.7-5 Common UNIX Printing System(tm) - ii hplip-data 2.8.4-1 HP Linux Printing and Imaging - da ii libc62.7-10 GNU C Library: Shared libraries ii libcupsys2 1.3.7-5 Common UNIX Printing System(tm) - ii libdbus-1-3 1.2.1-2 simple interprocess messaging syst ii libjpeg626b-14 The Independent JPEG Group's JPEG ii libsane 1.0.19-6API library for scanners ii libsnmp155.4.1~dfsg-7+b1 SNMP (Simple Network Management Pr ii libssl0.9.8 0.9.8g-10 SSL shared libraries ii libusb-0.1-4 2:0.1.12-11 userspace USB programming library ii lsb-base 3.2-11 Linux Standard Base 3.2 init scrip ii python 2.5.2-1 An interactive high-level object-o ii python-dbus 0.82.4-2simple interprocess messaging syst ii python-imaging 1.1.6-2 Python Imaging Library ii python-support 0.7.7 automated rebuilding support for P Versions of packages hplip recommends: ii cupsys-client 1.3.7-5 Common UNIX Printing System(tm) - ii hpijs 2.8.4+2.8.4-1 HP Linux Printing and Imaging - gs ii hpijs-ppds 2.8.4+2.8.4-1 HP Linux Printing and Imaging - HP ii hplip-gui 2.8.4-1 HP Linux Printing and Imaging - GU ii openprinting-ppds 20080211-2OpenPrinting printer support - Pos ___ Pkg-hpijs-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-hpijs-devel --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476126: Bug:#476126 hplip: postrm attempts to remove group scanner unconditionally
Mark Purcell wrote: Sorry about the delay, yes I agree this would be good to resolve before lenny. hplip also checks for the scanner group and adds it if necessary. But hplip also depends on libsane. Is hplip able to rely on libsane to add and remove the scanner group as required? If libsane manages completely that the scanner group exists throughout the whole presence of libsane, HPLIP does not need to take care of the group. If libsane does so only from a given version on, then make the dependency in HPLIP versioned. Looking through launchpad[1] I see that they are now using HAL rather than the scanner group for access. Is that relevant to debian? I do not know whether Debian switched to HAL, too. If so, one could drop the scanner group even in libsane. In general I would keep the scanner group, so that the admin can add (trusted) users to the group scanner if they want to scan from an ssh login or if the machine provides desktops to remote machines through tools like VNC or NX. Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483205: [Pkg-hpijs-devel] hplip: group scanner requirements.
I think it is not good to put users into the lp group so that they can use the hp-toolbox. Members of the lp group can read other user's print jobs. It should be introduced a new group for user access to desktop peripherals. Only desktop users (not system users like lp) should be member of this group so that they can scan, see ink levels, and do other desktop peripheral access tasks. The admin or the distro could decide to have all desktop users in this group or only the one user currently logged in to the desktop. Till Mark Purcell wrote: Till, With reference to our earlier discussion (below) we have been having further discussion about the udev rules in the pkg-hpijs mailing list. The outcome i think is that I may change the udev rule to set permissions to lp.lp and drop the whole idea of using group scanner. Also we won't set MODE as udev defaults are sane 0664. I just wanted to check that this won't cause you any issues. Mark -original message- Subject: Re: [Pkg-hpijs-devel] hplip: group scanner requirements. From: Till Kamppeter [EMAIL PROTECTED] Date: 24/06/2008 12:13 Mark Purcell wrote: On Sun, 22 Jun 2008, you wrote: I was just also receiving a code=12 error message and by adding myself to the scanner group. I am now able to access the device correctly through hp-toolbox. Yes, this fixed the problem. code=12 was a bit obtuse for you are not a member of the group scanner Arthur, Excellent, glad we have made some progress. But you are right the error message isn't sensible and the scanner group doesn't make sense for running hp-toolbox. The reason is that the USB device ownership is set lp.scanner, this is a Debian/ Ubuntu modification. Till, the upstream file ./data/rules/55-hpmud.rules sets the USB device OWNER=root, GROUP=lp, whilst the debian/ubuntu version debian/55-hpmud.rules sets OWNER=lp, GROUP=scanner. This has the effect that everyone trying to use hplip needs to be a member of group scanner to use things such as hp-toolbox, rather than the expected lp group. How would you feel if we reverted 55-hpmud.rules back to the upstream default of OWNER=root, GROUP=lp. Ubuntu from Hardy on sets ACLs for these files to make them always read/write accessible for the user currently logged in on the desktop. Adding users to a group, like scanner, is only needed if one wants to grant access to users who log in by ssh, VNC, NX, ... So for the standard configuration it does not matter whether the ownerships allow access for members of the group scanner. What is always important is to allow access for the lp user, so that CUPS can print. And this is also fulfilled with OWNER=root, GROUP=lp. Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483205: [Pkg-hpijs-devel] hplip: group scanner requirements.
Mark Purcell wrote: Till, Thanks for the comment. The other suggestion is to use lp.plugdev But the downside of that is there is then no way to distinguish between plugged in printers and other devices such as cameras. So the group ownership of a newly appearing device file is used to determine the type of plugged device (at least by certain apps)? Do you agree that using scanner is causing confusion for users who just wan't to use hp-toolbox and others? Yes, I think so. Therefore a desktop peripheral group would be the best solution. Has Ubuntu worked around this by using hal instead of udev? They set ACLs for the device files. These ACLs grant access to the user who is currently logged in on the desktop. They are set and removed by log in and log out, probably via PAM. Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482296: Rename package cupsys to cups
Package: cupsys Version: 1.3.7-1ubuntu3 Severity: important The cupsys packages (and all occurences of cupsys in the names of other packages) should be renamed to cups. First, no one who I have asked could tell me why in Debian and derivatives the CUPS package is called cupsys and not cups. Second, this is very awkward when it comes to user support (You do not know the user's distro and tell him /etc/init.d/cups restart) and when trying to create distro-independent LSB-based printing-related packages, like printer drivers from a printer manufacturer. I am the leader of the OpenPrinting project at the Linux Foundation and I have developed the LSB DDK to create distro-independent driver packages. The RPM macros which I have created to generate maintainer scripts which work with both Debian and non-Debian distros look really ugly. So cupsys should really be renamed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483205: [Pkg-hpijs-devel] hplip: group scanner requirements.
Mark Purcell wrote: On Sun, 22 Jun 2008, you wrote: I was just also receiving a code=12 error message and by adding myself to the scanner group. I am now able to access the device correctly through hp-toolbox. Yes, this fixed the problem. code=12 was a bit obtuse for you are not a member of the group scanner Arthur, Excellent, glad we have made some progress. But you are right the error message isn't sensible and the scanner group doesn't make sense for running hp-toolbox. The reason is that the USB device ownership is set lp.scanner, this is a Debian/ Ubuntu modification. Arthur. Wrt your ink supply Traceback, please file a new bug report, with upstream preferably, as you will see if you try and file a report with hplip 2.8.6. Till, the upstream file ./data/rules/55-hpmud.rules sets the USB device OWNER=root, GROUP=lp, whilst the debian/ubuntu version debian/55-hpmud.rules sets OWNER=lp, GROUP=scanner. This has the effect that everyone trying to use hplip needs to be a member of group scanner to use things such as hp-toolbox, rather than the expected lp group. How would you feel if we reverted 55-hpmud.rules back to the upstream default of OWNER=root, GROUP=lp. Ubuntu from Hardy on sets ACLs for these files to make them always read/write accessible for the user currently logged in on the desktop. Adding users to a group, like scanner, is only needed if one wants to grant access to users who log in by ssh, VNC, NX, ... So for the standard configuration it does not matter whether the ownerships allow access for members of the group scanner. What is always important is to allow access for the lp user, so that CUPS can print. And this is also fulfilled with OWNER=root, GROUP=lp. Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479397: RFA: gutenprint -- printer drivers for CUPS
Hi, I am maintaing Gutenprint and several other printing packages (drivers, HPLIP, Foomatic, Ghostscript, system-config-printer) for Ubuntu. Some of these packages (cupsys, hplip) are managed in Debian SVN repositories from which both Debian and Ubuntu packages are released. I (and also other developers) upload all the changes into these repositories which leads to one package maintenance effort for both distros. For HPLIP I usually update the package when there is a new upstream version or a fix of a bug reported to Ubuntu and Marc Purcell takes snapshots of the repository as Debian packages and puts in fixes of bugs reported to Debian. This way we can also proceed for Gutenprint. Open a Debian SVN repository for its debian/ directory and I will commit alll my changes there. So if there is no one at Debian having time to maintain the package it is enough to simply release this repo as a Debian package when I have released a new Ubuntu package. I can look also at Gutenprint bugs reported to Debian and forward them to upstream and fix packaging bugs which also break Ubuntu, but note that I have only Ubuntu and not Debian for testing and for tests on real printers I have only PCL printers (laser and inkjet), no Epson inkjets. How can I subscribe as bug contact to Gutenprint and HPLIP in Debian's bug tracker? Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#587272: warning from defoma: It is recommended to run defoma-app purge gs
I have fixed the problem in the Ubuntu package (8.71.dfsg.2-0ubuntu8), simply following the warning, adding defoma-app purge gs to the ghostscript.preinst script after all other defoma clean-up. Now the installation of this ghostscript package eliminates the defoma warning for all future package installations. debdiff attached. Till diff -u ghostscript-8.71.dfsg.2/debian/changelog ghostscript-8.71.dfsg.2/debian/changelog --- ghostscript-8.71.dfsg.2/debian/changelog +++ ghostscript-8.71.dfsg.2/debian/changelog @@ -1,3 +1,11 @@ +ghostscript (8.71.dfsg.2-0ubuntu8) natty; urgency=low + + * debian/ghostscript.preinst: Clean up traces of Ghostscript in defoma +via defoma-app purge gs, so that when updating packages which still +use defoma no warnings get issued (Closes: #587272). + + -- Till Kamppeter till.kamppe...@gmail.com Tue, 7 Dec 2010 23:59:59 +0100 + ghostscript (8.71.dfsg.2-0ubuntu7) maverick; urgency=low * debian/control: Updated versioned dependency of ghostscript on gsfonts, diff -u ghostscript-8.71.dfsg.2/debian/ghostscript.preinst ghostscript-8.71.dfsg.2/debian/ghostscript.preinst --- ghostscript-8.71.dfsg.2/debian/ghostscript.preinst +++ ghostscript-8.71.dfsg.2/debian/ghostscript.preinst @@ -31,6 +31,12 @@ rm -f /etc/defoma/ghostscript.subst-rule~ rm -f /var/lib/defoma/ghostscript.subst-cache fi + + # Purge old defoma stuff to avoid warnings from defoama when updating + # other packages which still use defoma +if dpkg --compare-versions $2 lt-nl 8.71.dfsg.2-0ubuntu8; then + defoma-app purge gs 2/dev/null || true + fi ;; abort-upgrade)
Bug#122415: gs vertically misaligns printed output
On 01/23/2011 02:23 PM, Jonathan Nieder wrote: gs -sDEVICE=stp \ This bug is obsolete. The built-in Ghostscript driver stp does not exist any more in current Ghostscript. It is replaced by the CUPS-Raster- and IJS-based flavors of Gutenprint. So this bug can be closed. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610928: Backward compatibility script needed for HP PPD upgrade
The Debian packages of HPLIP (hplip, hplip-cups, hpijs, and hpijs-ppds) should generally update the PPDs of the existing print queues to the current packages version in the post-install scripts. Can you attach the PPD(s) which did not get updated automatically to this bug report? Thanks. Till On 01/24/2011 02:47 AM, Kevin Shanahan wrote: Package: hpijs-ppds Version: 3.10.6-1.1 On upgrade from Lenny to Squeeze a number of our printer queues stopped working with the following error logged: D [24/Jan/2011:08:54:10 +1030] [Job 449496] prnt/hpcups/HPCupsFilter.cpp 361: DEBUG: Bad PPD - hpPrinterLanguage not found D [24/Jan/2011:08:54:10 +1030] [Job 449496] prnt/backend/hp.c 839: ERROR: null print job total=0 The upgrade also reset the default paper size to weird values on a bunch of other HP printers. I found this info on the redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=579355 I grabbed a copy of hpijs-3.10.9-1.fc12.x86_64.rpm, extracted the hpcups-update-ppds script and ran it. This fixed all the issues caused by the upgrade. Debian should have something like this for Squeeze. Regards, Kevin -- 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.
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.
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#615202: libgs8: SEGV in gs when called from pstoraster (and in other contexts)
Thank you for the nice bug report with fix. I will apply the fix upstreamm. I have no file to reproduce it. Can you send me your file by e-mail? Thanks. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503644: [Pkg-cups-devel] Bug#503644: cups: no IPP printer available any more?
Martin Pitt wrote: Hi Marc, Marc Haber [2008-10-27 10:03 +0100]: after upgrading to the experimental CUPS packages, I can no longer configure an IPP printer: The Device combo box in the Add and Configure Printer dialogs only shows AppSocket/HP JetDirect, Backend Error Handler, CUPS-PDF (Virtual PDF Printer), HP Fax (HPLIP), HP Printer (HPLIP), LPT #1, SCSI Printer and Windows Printer via SAMBA. Is this really any different with the unstable packages? My feeling is that this is an upstream decision, and it's like that for my printer, too. My IPP backend on Ubuntu Intrepid (uses the same CUPS package as Debian experimental) has the following permissions [EMAIL PROTECTED]:~/photos$ ll /usr/lib/cups/backend/ipp -rwxr--r-- 3 root root 28280 2008-11-11 09:55 /usr/lib/cups/backend/ipp [EMAIL PROTECTED]:~/photos$ Is this intended (to make CUPS run it as root)? lpinfo -v does noy list ipp for me. When I try to print a test page, the printer status says No %%Pages: comment in header!, but when I look into the actual spool file, it looks like PostScript alright. That seems to be a bug in one of the filters. Till, any idea how to debug this? First, the newest available CUPS package is needed. The one which comes with Intrepid has a bug in pstopdf. Second, for debugging filter chains you can use the cupsfilter command. Third, you can temporarily short-circuit pdftopdf via sudo -s mv /usr/lib/cups/filter/pdftopdf /usr/lib/cups/filter/pdftopdf.orig cat /usr/lib/cups/filter/pdftopdf EOF #!/bin/sh cat \$6 EOF chmod 755 /usr/lib/cups/filter/pdftopdf exit and undo it with sudo mv /usr/lib/cups/filter/pdftopdf.orig /usr/lib/cups/filter/pdftopdf Does the problem go away with the short-circuit? Forth, /usr/lib/cups/filter/pdftoraster is not feature-coomplete. Please test with my Ghostscript-based version: Download this file: http://www.openprinting.org/download/printing/ghostscript-cups-patches/pdftoraster.c Install the packages needed to compile it: sudo apt-get install libcups2-dev libcupsimage2-dev Compile it: gcc -lcups -lcupsimage -o pdftoraster pdftoraster.c Install it: sudo mv /usr/lib/cups/filter/pdftoraster /usr/lib/cups/filter/pdftoraster.orig sudo cp pdftoraster /usr/lib/cups/filter/ sudo chmod 755 /usr/lib/cups/filter/pdftoraster Now try to print again. Does it work now? Fifth, always run CUPS in debug mode (cupsctl LogLevel=debug) and have a look into /var/log/cups/error_log. Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505282: Simply merge the Ubuntu package
I suggest that you simply merge the current Ubuntu Jaunty package (ghostscript 8.63.dfsg.1-0ubuntu7) into Debian. It contains the new filter and many other important bug fixes. Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
Please merge the following Ubuntu package version of Ghostscript into Debian: 8.64.dfsg.1-0ubuntu11 It has the following fixes and new feature (in addition to the ones of 0ubuntu9 and earlier): - pstoraster did not work when called with an input file name as the 6th command line argument. - The ps2write output device produces PostScript which is not DSC-conforming, so do not advertize it as DSC-conforming with a %!PS-Adobe-... magic string. Use %! instead. Otherwise the pstops CUPS filter cannot handle this output (https://bugs.launchpad.net/bugs/377011). - Fixed recognition of page size via /cupsPageSizeName in the cups output device. All page sizes were considered custom sizes if /cupsPageSizeName was not set. - Splitted off the CUPS-related files into its own package, so that the requirements of cups and cups-client for the automatic update of the PPDs of existing print queues do not apply to the ghostscript core package. Added cups and cups-client to the Depends: entry of the new ghostscript-cups package, so that the automatic updates of the PPDs also works on updates to a new release of the distribution and not only on single-package updates. Added also perl as dependency to the ghostscript-cups package as it is also needed for the automatic PPD updates. Especially the second and the last change are necessarily needed in Debian, to avoid that the CUPS packages have to be different in Debian and Ubuntu. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hi Till and others, On Sun, May 24, 2009 at 08:44:43PM +0200, Till Kamppeter wrote: Please merge the following Ubuntu package version of Ghostscript into Debian: - pstoraster did not work when called with an input file name as the 6th command line argument. - The ps2write output device produces PostScript which is not DSC-conforming, so do not advertize it as DSC-conforming with a %!PS-Adobe-... magic string. Use %! instead. Otherwise the pstops CUPS filter cannot handle this output (https://bugs.launchpad.net/bugs/377011). - Fixed recognition of page size via /cupsPageSizeName in the cups output device. All page sizes were considered custom sizes if /cupsPageSizeName was not set. Above is in Git already (cherry-picked from upstream yesterday). Thank you very much. - Splitted off the CUPS-related files into its own package, so that the requirements of cups and cups-client for the automatic update of the PPDs of existing print queues do not apply to the ghostscript core package. Added cups and cups-client to the Depends: entry of the new ghostscript-cups package, so that the automatic updates of the PPDs also works on updates to a new release of the distribution and not only on single-package updates. Added also perl as dependency to the ghostscript-cups package as it is also needed for the automatic PPD updates. Sounds interesting. Is the perl dependency for the defoma code currently in ghostscript postinst? I haven't look closely at it, but is perl-base not sufficient? I have added the Perl dependency because the PPD updater in the ghostscript-cups.postinst script calls Perl, simply to do string manipulations with Perl's RE engine. If perl-base is enough for that purpose, please tell me, as I will add this dependency also to other packages (all printer drivers). I do not know what Defoma needs. I hope Defoma is dependent on that by itself, so that Ghostscript only needs to be dependent on Defoma. Could you please post a diff of this one change isolated - preferrably against the packaging work in Git? Or even better just applied directly to our Git here: git://git.debian.org/git/collab-maint/ghostscript.git. This is the diff between the Ubuntu package containing the ghostscript-cups split and the previous package. It contains exactly the changes done to do the split plus the dependency additions for the new package. http://launchpadlibrarian.net/26911463/ghostscript_8.64.dfsg.1-0ubuntu9_8.64.dfsg.1-0ubuntu10.diff.gz Especially the second and the last change are necessarily needed in Debian, to avoid that the CUPS packages have to be different in Debian and Ubuntu. I do not consider Ubuntu upstream to Debian. It makes much better sense to me to do coordinated work together on the Debian package. Me not, too. I suggest to overtake these changes into Debian, once to make it possible that the CUPS package can stay synced (be the same in both Debian and Ubuntu), and second, as the CUPS package in Debian is switched to the PDF printing workflow (http://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format), to fix bugs in Ghostscript which cause problems in the PDF printing workflow, mainly bugs in PDF - PostScript conversion. That said, I appreciate you informing about changes in Ubuntu, I will certainly cherry-pick changes that makes sense for Debian (which might very well be all of it). OK, I usually only ask Debian to ask for overtaking my changes in Ubuntu or upstream, if it simplifies the Debian/Ubuntu logistics or fixes important problems. As I am leading the OpenPrinting project I am often introducing new technologies into the printing infrastructure, and because I am Ubuntu developer they go to Ubuntu at first. The parts in CUPS they go automatically into Debian, as the CUPS packagfe is synced, but sometimes changes in CUPS depend on changes in other which are not synced. Thanks again for your cooperation. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
Jonas Smedegaard wrote: perl-base is sufficient if no modules are loaded, which is the case for the postinst routines. Perl-base is part of base so need not be declared as a dependency (except for versioned dependencies). You are right that defoma should care for its own dependencies. All in all: Please drop that perl dependency. Will do in Ubuntu's SpliX and Ghostscript, and only add cups and cups-client to the other driver packages. In all these cases we have only the simple perl -p -i -e ... calls in postinst, no applications written in Perl. The Debian package has evolved, but above changes are pretty simple, so I can easily reimplement using the new packaging structure of 8.64-4. I hesitate doing it right now, however: this change is a new feature, not a bugfix, and adding new binary packages has a risk of delaying acceptance into Debian. Who has to accept it? Masayuki Hatta, the Ghostscript maintainer? Or also other people? Is unstable in a release freeze currently? I would therefore prefer to finalize the other changes currently released in experimental (I just released -4 a moment ago), and _after_ that implement this last change. OK. What I want fixed for the package to enter unstable is this: a) symbols handling b) reduce linking c) coordination with dependent packages All three are related: Library symbols are supposed to be stable, but changes to compile flags change symbols, and recent changes even made some symbols disappear that was declared earlier on (libcairo was enabled for a short time, and at least on arm and i386 it offered some symbols that are now gone). I suspect that some symbols should not even be public, but do not understand library linking that well, so I might be completely off track here... The libcairo use in Ghostscript (Cairo output device) was dropped as it made the Ghostscript core pulling X and exactly for that the X output devices got modularized into ghostscript-x. The Cairo output device can only get reintroduced in the distro packages if it also gets modularized like the X devices. I have cleaned up and added symbols since release of Lenny. But for some reason they are not used during install (probably some ordering issue between debhelper, CDBS and d-shlibdeps). the linking routine warns about excess linking. I do not know if fixing that affects symbols or not. When symbols are working properly to track changes at each release, we can contact package maintainers that link against ghostscript and coordinate with them to verify that nothing breaks linking against our cleaned up release. This seems to be only cups, foomatic-filters and libspectre, but I have checked only binary dependencies using aptitude, do not know how to look up source dependencies). foomatic-filters links only against documented symbols of the Ghostscript API. So it cannot break on the disappearing of stray symbols like from Cairo. Which parts of CUPS link against Ghostscript? AFAIK the CUPS filters call Ghostscript via the command line. As you might notice from above, I really am fumbling here - I am not a C library expert. So any help would be much appreciated. Oh, a related thing: I included a static library, as I believe is required by Debian Policy. But I suspect it is not compiled correctly: All code is currently compiled with -cPIC and if I recall correctly static library needs to be compiled _without_ -fPIC. Upstream build routines seem to handle -fPIC correctly - except for the X11 driver, which fails to build using --shared if -fPIC is not explicitly added to CFLAGS (causing it to be added twice in many places). So if I am right that static lib needs to not use -fPIC then the package needs to either a) patch ghostscript build routines related to X11 driver, or b) compile everything twice - once as now, and another without --shared or -fPIC. In addition to these, there is also a simpler task: check with various bugreports if the issues are solved with the experimental package, and test if it works properly at all. Especially the second and the last change are necessarily needed in Debian, to avoid that the CUPS packages have to be different in Debian and Ubuntu. I do not consider Ubuntu upstream to Debian. It makes much better sense to me to do coordinated work together on the Debian package. Me not, too. I suggest to overtake these changes into Debian, once to make it possible that the CUPS package can stay synced (be the same in both Debian and Ubuntu), and second, as the CUPS package in Debian is switched to the PDF printing workflow (http://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format), to fix bugs in Ghostscript which cause problems in the PDF printing workflow, mainly bugs in PDF - PostScript conversion. Yes, I am looking forward to that switch. The switch is already there, the problems were that PDF - PostScript
Bug#528386: More Ghostscript changes which need to get into Debian: Split off a ghostscript-cups package
Jonas Smedegaard wrote: By Debian social norms, Masayuki Hatta has to accept it. He is a quiet guy, however, and these mails are cc'ed the package, reaching all team members. So I would say that the lack of response, keyed with earlier approval of moving to Git in the collab-maint group, can be interpreted as implicit approval. So please, let's move on :-) OK. Is unstable in a release freeze currently? Nope. But the term unstable in Debian unstable refer to the distro, not each package, and library changes should be treated with care at all times (something I have learned the hard and embarrasing way with libgd and uw-imap). The split is not a library change. the binary packages libgs8 and libgs-dev do not change by this step. The only changes in the libraries are all the cherry-picked bug fixes, but none of them changes the API. They only improve the stability and the correctness of the output. Yes, I understood that from changelog entries. Thanks for confirming. My point above is that packages have been released that contained those symbols related to libcairo linkage, and in principle there is now a risk of other packages relying on those symbols and thus need rebuilding and/or patches. the libcairo symbols was one example - other symbols have disappeared too since the release of Lenny (I have not kept symbols earlier than that). Also, concretely for the libcairo linkage, we should perhaps reconsider if pulling in X11 libraries is still evil: With the improved X11 packaging it might no longer be too much of a burden. To avoid pulling X11 is important for using head-less servers as print servers. They need to run Ghostscript but one wants to avoid installing X libraries only to satisfy Ghostscript's dependencies. The libgd package has similarly been provided both with and without X11 linkage to optionally avoid bloat, but I expect to drop that now, as the bloat is no longer as large as a few years ago. As the X itself is already split, I would like to leave it this way. The Cairo interface is still experimental AFAIK. So before doing changes here I would like to know if the Cairo interface is already considered stable. Right. Checking only binary dependencies as I did can cause false positives like that. But the potential list is longer: there's a bunch of packages depending only on ghostscript-x even if at least one of them () is known to link against libgs8. Can you tell which packages? Excellent. I notice now that you are also member of collab-maint, so you already have write access to the ghostscript Git :-D git clone ssh://till-gu...@git.debian.org/git/collab-maint/ghostscript Feel free to commit changes directly there. Except for adding new binary packages - please postpone such changes until after we've released to unstable. Oh, and if you are unfamiliar with some of the advanced CDBS features then try read the README.source file and if still puzzled (e.g. about the content of control.in and rules files) then please ask. OK. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530731: Please update Poppler to 0.11.0 in unstable
Package: poppler Currently unstable uses Poppler 0.10.x. For introducing the new pdftoopvp CUPS filter into the cups package (for the PDF printing workflow: https://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format) I need that unstable has at least Poppler 0.11.0. Can you update to that version? Thanks in advance. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555892: ptouch-driver -- CUPS/Foomatic driver for Brother P-touch label printers
I have packaged this driver now for Ubuntu, available as ptouch-driver in the Universe repository of Lucid. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605397: hplip: Won't print anything (gives unsupported format message)
On 11/29/2010 10:55 PM, Sam Morris wrote: This was solved by installing ghostscript-cups. It is only Recommended by cups; should hplip depend on it? The binary package hplip-cups should depend on it, as this package contains a CUPS Raster driver which needs ghostscript-cups. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605397: hplip: Won't print anything (gives unsupported format message)
On 11/29/2010 10:55 PM, Sam Morris wrote: This was solved by installing ghostscript-cups. It is only Recommended by cups; should hplip depend on it? Since HPLIP 3.9.6b-1 (exactly 3.9.4b-1ubuntu4) the hplip-cups package depends on ghostscript-cups. So for all Debian releases with this HPLIP version or a newer one this bug should be fixed. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593338: CUPS filters produce postscript that hangs Ricoh Aficio 3035
Hi, in the Debian bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593338 a user complains that his Ricoh Aficio 3035 printer hangs when printing from Debian on it. Probably the PostScript going to the printer is somehow broken. George, Bin, Ulrich, can someone of you please check with an appropriate Debian (or Ubuntu) installation whether the PostScript output is OK? And if not, tell us what needs to be corrected? Thanks in advance. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593338: CUPS filters produce postscript that hangs Ricoh Aficio 3035
On 09/07/2010 06:26 AM, Timo Juhani Lindfors wrote:
Note that even if you don't have an appropriate a Debian or Ubuntu
installation you can still look at the PostScript output. It is
available in
http://www.cups.org/str.php?L3646+P0+S-2+C0+I0+E0+M1000+Q
as port9100_1.4.4-2.dump.
I have printed this file on an HP LaserJet P3005 without filtering,
using the command
nc -w1 192.168.2.115 9100 port9100_1.4.4-2.dump
The printer prompted for inserting A4 paper and as I have A4 paper in
the tray, it seems that in this job manual paper feed is set. After
confirming the prompt pressing the OK button on the printer twice the
job got printed.
I have looked into the file, most probably either the
[{
%%BeginFeature: *RIPaperPolicy PromptUser
/DeferredMediaSelection true setpagedevice
/Policies /PageSize 2 /MediaType 2 setpagedevice
%%EndFeature
} stopped cleartomark
or the
[{
%%BeginFeature: *InputSlot 1Tray
/MediaPosition 1 setpagedevice
%%EndFeature
} stopped cleartomark
caused the printer to switch to manual feed.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596467: libsane-hpaio: only works if hplip is installed
Fixed in Debian SVN repo and on Ubuntu in HPLIP 3.10.6-1ubuntu6. The fix will appear in the next HPLIP upload to Debian. Thanks for reporting the bug. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596467: Please make libsane-hpaio recommend hplip (not depend on)
On 09/12/2010 02:22 PM, Pascal Dormeau wrote: I had a look to the way this problem is solved for Ubuntu in Launchpad (make libsane-hpaio depend on hplip) and I believe this solution will prevent users from installing libsane-hpaio in stand-alone (without hplip), as publicized in the package description: This package is useful for a minimal footprint headless scanning solution I may have seen only a limited part of the problem, but from my own experience, it seems that the only thing missing is a /etc/hp/hplip.conf containing a stanza with the path to the data directory. Like this: [dirs] home=/usr/share/hplip And of course, a little explanation in a README.Debian. Making libsane-hpaio recommend hplip will prevent problems for most users, and will allow minimal installation (I can use my psc1510 with only hpijs and libsane-hpaio), even if creating the /etc/hp/hplip.conf like above solves only a part of the problem encountered by the original poster. Much better this way. I have implemented it as follows now (in the Debian SVN repo, release 3.10.6-1ubuntu7): - libsane-hpaio recommends hplip. - The file /etc/hp/hplip.conf moved from hplip to libsane-hpaio. This makes libsane-hpaio work without hplip. - As hplip needs /etc/hp/hplip.conf hplip depends on libsane-hpaio again, as before (It was even wrong to lift this dependency as /usr/share/hplip/data/models/models.dat was already in libsane-hpaio). Now it is assured that libsane-hpaio always works and minimum installations are possible. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596467: Please make libsane-hpaio recommend hplip (not depend on)
The setting of the PPD paths via the post-install script of hplip is no problem. libsane-hpaio does not need these paths, so nothing breaks if hplip gets installed after libsane-hpaio. In addition, hplip sets the paths to places where itself provides The PPD files. We do not expect any users to change them to personal preferences. Till On 09/13/2010 08:21 PM, Pascal Dormeau wrote: Glad to see that did not chose the depend way. However, i have a remark about the hplip.conf file. Before this bug was opened, I tried to dig myself into the hplip related packages and yes the hplip.conf was shipped (up to now) with the hplip package. It seems that it is still updated after installation through the hplip postinst script (to fix PPD file paths). Could it be harmful (for instance a user that first installs libsane-hpaio then later decides to install hplip)? Well, I raise the question just in case (I guess there is no problem because there is no reason to modify the file with only libsane-hpaio installed), and I am quite sure that you have regarded this already. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598248: foomatic-db-engine: Takes a long time to spool/print after recent upgrade
I do not see any functional changes between foomatic-db-engine 4.0.4-2 and 4.0.4-3. Can you downgrade to 4.0.4-2 to see whether this fixes your problem? Can you attach your printer's PPD file (in /etc/cups/ppd/) once with 4.0.4-2 installed and once with 4.0.4-3 installed? Which driver are you using? 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.
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
Bug#598248: foomatic-db-engine: Takes a long time to spool/print after recent upgrade
The 2 PPD files are absolutely identical. Are you sure that you have tested printing the same file in the two cases (please attach the file) and that you have downgraded only foomatic-db-engine (not any other package like foomatic-filters, ghostscript, ...)? Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598639: foomatic-gui/printconf: Not working in modern CUPS environments
Package: foomatic-gui Version: 0.7.9.3 Severity: serious The printer setup tools provided by the foomatic-gui source package, printconf and foomatic-gui are not usable any more in modern CUPS environments. There are several problems which make the mentioned printer setup tools not working with modern CUPS environments. 1. Only PPDs generated by Foomatic are supported. Instead of asking CUPS for available PPDs/drivers (lpinfo -l -m or appropriate IPP request) it only looks up the local Foomatic XML database in /usr/share/foomatic. This makes a lot of available drivers not seen: a. Ready-made PPDs in /usr/share/ppd and subdirectories (PPDs for PostScript printers supplied by the printer manufacturers, SpliX, foo2zjs, LSB-based driver packages from OpenPrinting) b. PPDs supplied via PPD generators in /usr/lib/cups/driver/ (CUPS Raster driver of Gutenprint, compressed PPD file archives of newer packages, like ijsgutenprint-ppds, foomatic-db-compressed- ppds) c. PPD files generated on-the-fly by the CUPS DDK with CUPS DDK .drv source files in /usr/share/cups/drv/ (HPLIP, CUPS' own PPD files). So the newest and most sophisticated, especially manufacturer-supplied drivers are not available through printconf and foomatic-gui. This can lead to a lot of false bug reports due to unsupported printers. At least for CUPS a printer setup tool should not directly access the Foomatic XML data. Once, the data is available through the /usr/lib/cups/driver/foomatic PPD generator, and second, other PPD sources available to CUPS can be used, without taking care of them individually. 2. (Only printconf) Use of deprecated device-based USB URIs, like usb:/dev/usb/lp0. These URIs are not supported by CUPS any more as they only work if there is only one USB printer connected to the machine. As soon as there is more than one USB printer print queues (with model-specific drivers) do not stay assigned to the correct printer after rebooting. Therefore the new device-ID-based URIs have to be used. foomatic-gui uses them though. Possible fixes are: 1. (A lot of work and re-inventing the wheel) Fix the software to poll the PPD/driver info and the PPDs itself from CUPS when CUPS is in use. 2. Let foomatic-gui and printconf conflict with the cups package, so that they do not get installed on systems where the printing environment is CUPS. 3. Remove the foomatic-gui package from Debian altogether (recommended if upstream development has been discontinued). Recommended replacement for CUPS users is system-config-printer. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528386: Please merge new Ubuntu Ghostscript into Debian
Package: ghostscript I have made a new Ubuntu package of Ghostscript (in Karmic) to fix some bugs and to add the cdnj500 driver for the HP DesignJet 500 and 800. Most important change is that the ps2write device does not segfault on the testfile.pdf of the CUPS test suite any more, so that we can use it for CUPS filters (see http://bugs.ghostscript.com/show_bug.cgi?id=690475). Using ps2write in the pdftops CUPS filter solves several problems occuring with the currently used pswrite device: https://bugs.launchpad.net/bugs/361772 https://bugs.launchpad.net/bugs/362186 https://bugs.launchpad.net/bugs/369503 Once you have uploaded Ghostscript into Debian, Martin Pitt and me will switch over the pdftops filter in the CUPS package and upload it into both Debian and Ubuntu. Thanks in advance for your cooperation. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528386: Acknowledgement (Please merge new Ubuntu Ghostscript into Debian)
The source for the current Ubuntu package of Ghostscript you find here: https://launchpad.net/ubuntu/+source/ghostscript Click on the newest package in the list (currently 8.64.dfsg.1-0ubuntu9). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517297: [Pkg-hpijs-devel] Bug#517297: hplip udev rules never match
Mark Purcell wrote: On Tuesday 10 March 2009 10:11:17 Christopher Martin wrote: I'm happy to answer questions. Chris, Till, Seems that the udev rules are again causing problems. Lots of Debian bugs reported :-( Till. You reinstated our own udev rules with 2.8.12-1ubuntu5 which fixed a number of issues for ubuntu. Do we need to rework again, or are upstream 3.9.2 udev rules good? If possible, I wouldn't like to merge from upstream and would rather pass fixes like the enclosed directly upstream: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517297 Aaron, What is the best way we can work with you together on this? Mark I returned to having Ubuntu's own UDEV rules file due to the following bug reports: https://bugs.launchpad.net/bugs/319660 Cannot edit configuration from udev rules https://bugs.launchpad.net/bugs/319661 Must not set OWNER in udev rules https://bugs.launchpad.net/bugs/319662 udev rules should be 40-*.rules unless there's a good reason https://bugs.launchpad.net/bugs/319665 Uses deprecated SYSFS instead of ATTR Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515918: cups: prints raw source of PDF files
Paul van Tilburg wrote: I forgot to mention that I'm printing via the CUPS server of the faculty (so DeviceUri ipp://host/printers/ps7z1). In this case I do not now which CUPS server (mine or theirs) is responsible for doing what, so this might be relevant information too. The faculty CUPS server seem to run CUPS 1.3.9 on Fedora. I cannot reproduce the problem with the given files on a local printer. For me the printout always comes out correctly. Probably it is really a problem with the server. Are you printing into a raw queue perhaps? Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532097: RFC: Forming a Printing Task Force (was RFA: cups -- Common UNIX Printing System)
I think this is a good idea. We are currently in sync with the following packages: - cups (pitti + me) - foomatic-db (OdyX + me) - foomatic-db-engine (OdyX + me) - hplip (Mark Purcell + me) Other printing-related packages are - ghostscript - foomatic-filters - gutenprint - foo2zjs - splix - pnm2ppa - min12xxw - m2300w - pxljr - cjet - system-config-printer - python-cups Note that I have taken this list from Ubuntu. It is possible that Debian has even more packages, especially also for non-CUPS workflows (these are not supported by Ubuntu). foomatic-filters will be synced between Ubuntu and Debian soon, too (OdyX + me). Till On 07/01/2010 03:40 PM, Didier 'OdyX' Raboud wrote: Hi all, I'm answering to RFA bug #532097, CC'ing to various printing-related packages and to pkg-cups-de...@l.a.d.o. Please followup to the pkg-cups-devel list (if that's OKay). === Preamble === I just joined Chris Lawrence, along with Till Kamppeter in maintaining some foomatic-* packages. Then I noticed the big² pile of work in ghostscript, cups and many surrounding packages. I don't intend to fingerpoint specific people or teams, but the situation is worrying : some unresolved security issues, many RC bugs, tons of bugs, an increasing diff with Ubuntu, etc. My perception of the problem is that the forces are currently divided between Ubuntu and Debian. It seems that Ubuntu is better than Debian in keeping up with patches, etc. In my humble opinion, it is now time to get those patches back to Debian and merge our forces towards a better printing experience for both Debian and Ubuntu users. === Proposal === I propose to form a Printing Task Force that would join the Debian and Ubuntu forces around common repositories: there is almost never interest in keeping a diff between Debian and Ubuntu. This group would handle the following packages: cups ghostscript foomatic-* ? other ones ? Would there be some interest in such a group ? What other packages would suit ? Thanks in advance, cheers, OdyX N.B. I intentionally kept out of the discussion the implementation details such as $VCS choice, mailing-list or group name, etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590163: Changes in foomatic-db
To save space, the PPDs in foomatic-db got compressed. They are all compressed in the /usr/lib/cups/driver/openprinting-ppds and /usr/lib/cups/driver/openprinting-ppds-extra files. CUPS extracts needed PPD files automatically.Nothing will change for you if you set up printers with the web interface (http://localhost:631/) or with system-config-printer. For command-line-based printer setup proceed as follows: # lpinfo -m | grep 1320 | grep -i postscript foomatic:HP-LaserJet_1320-Postscript.ppd HP LaserJet 1320 Foomatic/Postscript hplip:HP/hp-laserjet_1320n-ps.ppd HP LaserJet 1320 series Postscript (recommended) # lpadmin -p lj -E -v parallel:/dev/lp0 -m hplip:HP/hp-laserjet_1320n-ps.ppd -o PageSize=A4 -o sides=two-sided-long-edge -D HP LaserJet 1320 # lpadmin -d lj Note that the -m option of lpadmin is used with the PPD URI. The PPD URI is the first word of each output line of lpinfo -m. Simply copy and paste the PPD URI for your desired printer/driver combo. I suggest these instructions to be added to the documentation for the package (README.debian etc.). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590163: Changes in foomatic-db
OdyX, you are partially wrong. The OpenPrinting database, available through the OpenPrinting web site ot through the foomatic-db package, provides two types of data: 1. XML files from which the pages of the OpenPrinting web site and also PPD files, the so-called Foomatic PPDs are generated. On the local system the foomatic-db-engine package generates the PPDs. The link /usr/lib/cups/driver/foomatic makes CUPS auto-generating the PPDs on-the-fly, so that they are available in printer setup tools and also if one creates a print queue on the command line as I showed in my previous posting. 2. Ready-made PPD files. Many PPD files are available as physical PPDs. These files are provided by printer manufacturers, mainly for PostScript printers and some also for PCL printers. If you install foomatic-db from upstream, (2) causes a much higher disk occupation than (1), even if each PPD file is individually gzipped. The former foomatic-filters-ppds package contained all Foomatic PPDs from (1) pre-built as ready-made PPDs and the PPDs of (2) plus the foomatic-filters package. So this was a one-package solution without need of generating PPDs, so mainly for easy use with CUPS 1.1.x (no PPD generator support) or non-CUPS spoolers. foomatic-db-engine was not needed. So this package was a major disk space killer, so completely unsuitable for live CDs or CUPS installations on routers. The foomatic-db source package builds three binary packages: 1. foomatic-db: This package contains the XML data of the OpenPrinting database, no PPD files. 2. openprinting-ppds and openprinting-ppds-extra: These two packages contain all manufacturer-supplied physical PPDs, and no PPDs generated from Foomatic XML data. The splitting into two packages was done to be able to ship the most important PPDs on the Ubuntu Desktop CD without occupying to much of the CD space with PPD files. These packages DO NOT contain any PPD files which is generated from the Foomatic XML data of (1). The change we have done is to replace the PPDs which are present as physical files in the openprinting-ppds and openprinting-ppds-extra packages by one single highly (but losslessly) compressed file from which CUPS automatically extracts the PPDs needed. The compressed PPDs are in the files /usr/lib/cups/driver/openprinting-ppds /usr/lib/cups/driver/openprinting-ppds-extra This leads to the following savings (on Ubuntu Maverick): Binary Package *.deb file installed system openprinting-ppds ~4 MB ~5 MB openprinting-ppds-extra~18 MB ~28 MB Compression is by a factor of 10 better than file-by-file gzip compression. See also http://pypi.python.org/pypi/pyppd https://bugs.launchpad.net/bugs/493282 hplip-data ballooned by 2.5 MB in lucid https://bugs.launchpad.net/bugs/446245 lzma more efficient than gzip Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590163: Changes in foomatic-db
Note also that PPDs for most HP printers are not provided by the OpenPrinting database and therefore not provided by foomatic-db any more for longer time. This is because HP ships their PostScript PPDs with the HPLIP package and maintains them there (and I do not want to ship redundant and unmaintained PPDs in foomatic-db). So these PPDs are provided by our hplip package, in the binary package hplip-data. So for your HP printer you should install hplip or at least hplip-data so that you get HP's most current PPD file for your printer. Note that from the next hplip package on the PPDs will also be compressed. hplip-data will then provide only the /usr/lib/cups/driver/hplip file and not the individual PPDs any more. Then you have to proceed as in my first comment to set up your printer. Savings in the next hplip-data package will be as follows: Binary Package *.deb file installed system hplip-data ~4 MB ~26 MB Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555892: RFP: ptouch-driver -- CUPS/Foomatic driver for Brother P-touch, label printers
Thank you for your work on packaging the ptouch driver. I have tried it and I have done the following changes: 1. I have corrected the upstream version number of the Debian package. It must be 0.13. 2. I have added a margin definition to the driver/ptouch.xml file assuming zero margins. Now the PPD coming out is the same as your hand-edited PPD. I did not do the following yet, but I would do it when making a Ubuntu package: 1. The 2 changes in the original source code should be supplied as patches 2. There should be a post-install script updating the PPD files of already existing print queues as all Ubuntu printer driver packages have. The new ptouch-driver_0.13-1.diff.gz is attached. make sure to rename the upstream tarball to ptouch-driver_0.13.orig.tar.gz when using the new .diff.gz. Till ptouch-driver_0.13-1.diff.gz Description: Unix tar archive
Bug#555892: RFP: ptouch-driver -- CUPS/Foomatic driver for Brother P-touch, label printers
Sorry, I had the wrong tarball. Upstream version 1.3 was correct. Attached is the fixed .diff.gz for upstreamversion 1.3 with the correct margin definition. Till ptouch-driver_1.3-1.diff.gz Description: Unix tar archive
Bug#544172: Fwd: [Pkg-cups-devel] Bug#544172: cups: please remove useless composite filter cpdftocps
No, this is a part of the PDF printing workflow. As PDF is the standard job format, PostScript printers need a driver now, which turns PDF to PostScript and especuially inserts the option code of the PPD into the PostScript output. This is done by the cpdftocps filter. Transforming incoming PostScript into PDF and then back to PostScript is done to do page management (N-up, even/odd pages, reverse order, selected pages, ...) on a PDF data stream (done by pdftopdf), as in PDF you can always reliably tell the pages apart. The incoming PostScript data often comes in non-DSC-conforming form (note that PostScript is a programming language) and so the page management simply does not work, leading to broken printouts or even no printout at all. Note also that the cost factors are not the expected CPU load, but a way of control to get the preferred filters used if there is more than one solution. See also http://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format Till Martin Pitt wrote: Hello Till, cpdftocps is a local filter, is this obsolete? Thanks, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530731: Please update Poppler to 0.11.0 in unstable
Please also add the following bug fix patches (they are both accepted
into Poppler upstream):
https://bugs.freedesktop.org/show_bug.cgi?id=20420
pdftops produces broken Postscript
15_poppler-ps-output-broken-binary-encoding-fix.patch
https://bugs.freedesktop.org/show_bug.cgi?id=19777
pdftops command line utility does not convert multiple-page-size
documents correctly
10_pdftops-multiple-page-size-support.patch
The first patch makes the CUPS pdftops filter reliably working also on
PDF files with embedded images. The second allows converting PDF files
with pages of different sizes so that the resulting PostScript file has
the page sizes conserved. The patches are needed for correct printing
with CUPS on PostScript and on many printers with manufacturer-supplied
drivers.
diff -Nur -x '*.orig' -x '*~' poppler-0.11.0/poppler/PSOutputDev.cc poppler-0.11.0.new/poppler/PSOutputDev.cc
--- poppler-0.11.0/poppler/PSOutputDev.cc 2009-05-11 19:59:09.0 +0200
+++ poppler-0.11.0.new/poppler/PSOutputDev.cc 2009-06-03 14:34:12.0 +0200
@@ -1269,6 +1269,7 @@
Object info, obj1;
switch (mode) {
+ case psModePSOrigPageSizes:
case psModePS:
writePS(%!PS-Adobe-3.0\n);
break;
@@ -1299,6 +1300,7 @@
writePS(%%DocumentSuppliedResources: (atend)\n);
switch (mode) {
+ case psModePSOrigPageSizes:
case psModePS:
writePSFmt(%%DocumentMedia: plain {0:d} {1:d} 0 () ()\n,
paperWidth, paperHeight);
@@ -3122,7 +3124,7 @@
GBool landscape;
- if (mode == psModePS) {
+ if (mode == psModePS || mode == psModePSOrigPageSizes) {
GooString pageLabel;
const GBool gotLabel = m_catalog-indexToLabel(pageNum -1, pageLabel);
if (gotLabel) {
@@ -3137,7 +3139,8 @@
} else {
writePSFmt(%%Page: {0:d} {1:d}\n, pageNum, seqPage);
}
-writePS(%%BeginPageSetup\n);
+if (mode != psModePSOrigPageSizes)
+ writePS(%%BeginPageSetup\n);
}
// underlays
@@ -3150,6 +3153,29 @@
switch (mode) {
+ case psModePSOrigPageSizes:
+x1 = (int)floor(state-getX1());
+y1 = (int)floor(state-getY1());
+x2 = (int)ceil(state-getX2());
+y2 = (int)ceil(state-getY2());
+width = x2 - x1;
+height = y2 - y1;
+if (width height) {
+ landscape = gTrue;
+} else {
+ landscape = gFalse;
+}
+writePSFmt(%%PageBoundingBox: {0:d} {1:d} {2:d} {3:d}\n, x1, y1, x2 - x1, y2 - y1);
+writePS(%%BeginPageSetup\n);
+writePSFmt(%%PageOrientation: {0:s}\n,
+ landscape ? Landscape : Portrait);
+writePSFmt(/PageSize [{0:d} {1:d}] setpagedevice\n, width, height);
+writePS(pdfStartPage\n);
+writePSFmt({0:d} {1:d} {2:d} {3:d} re W\n, x1, y1, x2 - x1, y2 - y1);
+writePS(%%EndPageSetup\n);
+++seqPage;
+break;
+
case psModePS:
// rotate, translate, and scale page
imgWidth = imgURX - imgLLX;
diff -Nur -x '*.orig' -x '*~' poppler-0.11.0/poppler/PSOutputDev.h poppler-0.11.0.new/poppler/PSOutputDev.h
--- poppler-0.11.0/poppler/PSOutputDev.h 2009-05-11 19:59:09.0 +0200
+++ poppler-0.11.0.new/poppler/PSOutputDev.h 2009-06-03 14:20:38.0 +0200
@@ -53,7 +53,8 @@
enum PSOutMode {
psModePS,
psModeEPS,
- psModeForm
+ psModeForm,
+ psModePSOrigPageSizes
};
enum PSFileType {
diff -Nur -x '*.orig' -x '*~' poppler-0.11.0/utils/pdftops.cc poppler-0.11.0.new/utils/pdftops.cc
--- poppler-0.11.0/utils/pdftops.cc 2008-11-08 20:00:30.0 +0100
+++ poppler-0.11.0.new/utils/pdftops.cc 2009-06-03 14:20:38.0 +0200
@@ -74,6 +74,7 @@
static GBool level2Sep = gFalse;
static GBool level3 = gFalse;
static GBool level3Sep = gFalse;
+static GBool doOrigPageSizes = gFalse;
static GBool doEPS = gFalse;
static GBool doForm = gFalse;
#if OPI_SUPPORT
@@ -115,6 +116,8 @@
generate Level 3 PostScript},
{-level3sep, argFlag, level3Sep, 0,
generate Level 3 separable PostScript},
+ {-origpagesizes,argFlag, doOrigPageSizes,0,
+ conserve original page sizes},
{-eps,argFlag, doEPS, 0,
generate Encapsulated PostScript (EPS)},
{-form, argFlag, doForm, 0,
@@ -202,8 +205,10 @@
fprintf(stderr, Error: use only one of the 'level' options.\n);
exit(1);
}
- if (doEPS doForm) {
-fprintf(stderr, Error: use only one of -eps and -form\n);
+ if ((doOrigPageSizes ? 1 : 0) +
+ (doEPS ? 1 : 0) +
+ (doForm ? 1 : 0) 1) {
+fprintf(stderr, Error: use only one of -origpagesizes, -eps, and -form\n);
exit(1);
}
if (level1) {
@@ -223,9 +228,10 @@
fprintf(stderr, Error: forms are only available with Level 2 output.\n);
exit(1);
}
- mode = doEPS ? psModeEPS
- : doForm ? psModeForm
-: psModePS;
+ mode = doOrigPageSizes ? psModePSOrigPageSizes
+ : doEPS ? psModeEPS
+ : doForm ? psModeForm
+ : psModePS;
fileName = new
Bug#530731: Please update Poppler to 0.11.0 in unstable
If you do not consider updating to 0.11.x as it is a development release, so please add the following two patches to the current Poppler in Debian, so that we can at least build CUPS with the new pdftoopvp print filter. This patch is required for building pdftoopvp: http://www.openprinting.org/download/printing/pdf-printing/poppler-ext.patch It makes the needed APIs available and it has only changes in 13 lines. This patch is highly recommended for pdftoopvp: http://www.openprinting.org/download/printing/pdf-printing/cms-all-090306.patch It introduces color management into Poppler. The patch is bigger (811 added lines). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533186: [Pkg-cups-devel] Bug#533186: Bug not fixed, sorry
Martin-Éric Racine wrote: 2009/6/18 Josselin Mouette j...@debian.org: Sorry, but cups depends on ghostscript-cups since it cannot work without it. AFAIK only certain printers depend on ghostscript-cups. Till can correct me if I'm wrong. Yes, that's it. ghostscript-cups contains the pdftoraster, pstoraster, and pstopxl filters and PPDs for the pstopxl filter. It is only needed for CUPS Raster drivers. Therefore the CUPS Raster driver packages of Ubuntu (splix, cups-driver-gutenprint, hplip-cups) depend on this package. Also lsb depends on this package as the LSB standardizes the CUPS Raster driver interface. Debian should also make these packages require ghostscript-cups. The cups package only recommends ghostscript-cups, as it is not always needed, for example if PostScript printers or printers with built-in Ghostscript drivers are used, this package is not needed. ghostscript-cups depends on cups, as CUPS must be running so that the PPD files of existing queues which use the pstopxl driver in this package get auto-updated when this package gets updated. In addtion, the files in ghostscript-cups only make sense together with CUPS. However, if we indeed depend upon ghostscript-cups because it was split from the main ghostscript package (a bad idea, IMHO), The splitting is done to avoid ghostscript to depend on CUPS for the PPD updating. ghostscript is often used without CUPS, for screen display or for use with non-CUPS printing environments (LPRng, ...). then we'll need to upgrade the Depends and Recommends of both ghostscript-cups and cups. The package dependencies which I have mentioned here are the ones implemented in Ubuntu Karmic. Please use the same ones in Debian. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533186: [Pkg-cups-devel] Bug#533186: Bug not fixed, sorry
Josselin Mouette wrote: Sure, if only the affected drivers need to depend on ghostscript-cups, it’s fine to put the dependency that way. But currently it is not here. Then the bug here is that these dependencies in the driver packages are missing. So assign this bug to splix, gutenprint, hplip, and lsb (and any other CUPS Raster driver package coming with Debian). Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530731: Replaced one of the proposed bug fix patches
On June 11 I have proposed two bug fix patches for the Debian package of
Poppler. One of them needs some additional changes to correctly work. So
do not use the
10_pdftops-multiple-page-size-support.patch
which I have attached to this bug report earlier, but the patch attached
to this e-mail. See the bug reports
https://bugs.freedesktop.org/show_bug.cgi?id=19777
https://bugs.launchpad.net/ubuntu/jaunty/+source/poppler/+bug/382379
for more about this new patch.
Thanks in advance.
Till
diff -Nur -x '*.orig' -x '*~' poppler-0.11.0/poppler/PSOutputDev.cc poppler-0.11.0.new/poppler/PSOutputDev.cc
--- poppler-0.11.0/poppler/PSOutputDev.cc 2009-05-11 19:59:09.0 +0200
+++ poppler-0.11.0.new/poppler/PSOutputDev.cc 2009-06-22 16:40:04.0 +0200
@@ -1269,6 +1269,7 @@
Object info, obj1;
switch (mode) {
+ case psModePSOrigPageSizes:
case psModePS:
writePS(%!PS-Adobe-3.0\n);
break;
@@ -1299,6 +1300,9 @@
writePS(%%DocumentSuppliedResources: (atend)\n);
switch (mode) {
+ case psModePSOrigPageSizes:
+prevWidth = 0;
+prevHeight = 0;
case psModePS:
writePSFmt(%%DocumentMedia: plain {0:d} {1:d} 0 () ()\n,
paperWidth, paperHeight);
@@ -3122,7 +3132,7 @@
GBool landscape;
- if (mode == psModePS) {
+ if (mode == psModePS || mode == psModePSOrigPageSizes) {
GooString pageLabel;
const GBool gotLabel = m_catalog-indexToLabel(pageNum -1, pageLabel);
if (gotLabel) {
@@ -3137,7 +3147,8 @@
} else {
writePSFmt(%%Page: {0:d} {1:d}\n, pageNum, seqPage);
}
-writePS(%%BeginPageSetup\n);
+if (mode != psModePSOrigPageSizes)
+ writePS(%%BeginPageSetup\n);
}
// underlays
@@ -3150,6 +3161,35 @@
switch (mode) {
+ case psModePSOrigPageSizes:
+x1 = (int)floor(state-getX1());
+y1 = (int)floor(state-getY1());
+x2 = (int)ceil(state-getX2());
+y2 = (int)ceil(state-getY2());
+width = x2 - x1;
+height = y2 - y1;
+if (width height) {
+ landscape = gTrue;
+} else {
+ landscape = gFalse;
+}
+writePSFmt(%%PageBoundingBox: {0:d} {1:d} {2:d} {3:d}\n, x1, y1, x2 - x1, y2 - y1);
+writePS(%%BeginPageSetup\n);
+writePSFmt(%%PageOrientation: {0:s}\n,
+ landscape ? Landscape : Portrait);
+if ((width != prevWidth) || (height != prevHeight)) {
+ // Set page size only when it actually changes, as otherwise Duplex
+ // printing does not work
+ writePSFmt(/PageSize [{0:d} {1:d}] setpagedevice\n, width, height);
+ prevWidth = width;
+ prevHeight = height;
+}
+writePS(pdfStartPage\n);
+writePSFmt({0:d} {1:d} {2:d} {3:d} re W\n, x1, y1, x2 - x1, y2 - y1);
+writePS(%%EndPageSetup\n);
+++seqPage;
+break;
+
case psModePS:
// rotate, translate, and scale page
imgWidth = imgURX - imgLLX;
diff -Nur -x '*.orig' -x '*~' poppler-0.11.0/poppler/PSOutputDev.h poppler-0.11.0.new/poppler/PSOutputDev.h
--- poppler-0.11.0/poppler/PSOutputDev.h 2009-05-11 19:59:09.0 +0200
+++ poppler-0.11.0.new/poppler/PSOutputDev.h 2009-06-22 16:40:04.0 +0200
@@ -53,7 +53,8 @@
enum PSOutMode {
psModePS,
psModeEPS,
- psModeForm
+ psModeForm,
+ psModePSOrigPageSizes
};
enum PSFileType {
@@ -333,6 +334,10 @@
PSOutMode mode; // PostScript mode (PS, EPS, form)
int paperWidth; // width of paper, in pts
int paperHeight; // height of paper, in pts
+ int prevWidth; // width of previous page
+// (only psModePSOrigPageSizes output mode)
+ int prevHeight; // height of previous page
+// (only psModePSOrigPageSizes output mode)
int imgLLX, imgLLY, // imageable area, in pts
imgURX, imgURY;
GBool preload; // load all images into memory, and
diff -Nur -x '*.orig' -x '*~' poppler-0.11.0/utils/pdftops.cc poppler-0.11.0.new/utils/pdftops.cc
--- poppler-0.11.0/utils/pdftops.cc 2008-11-08 20:00:30.0 +0100
+++ poppler-0.11.0.new/utils/pdftops.cc 2009-06-22 16:39:56.0 +0200
@@ -74,6 +74,7 @@
static GBool level2Sep = gFalse;
static GBool level3 = gFalse;
static GBool level3Sep = gFalse;
+static GBool doOrigPageSizes = gFalse;
static GBool doEPS = gFalse;
static GBool doForm = gFalse;
#if OPI_SUPPORT
@@ -115,6 +116,8 @@
generate Level 3 PostScript},
{-level3sep, argFlag, level3Sep, 0,
generate Level 3 separable PostScript},
+ {-origpagesizes,argFlag, doOrigPageSizes,0,
+ conserve original page sizes},
{-eps,argFlag, doEPS, 0,
generate Encapsulated PostScript (EPS)},
{-form, argFlag, doForm, 0,
@@ -202,8 +205,10 @@
fprintf(stderr, Error: use only one of the 'level' options.\n);
exit(1);
}
- if (doEPS doForm) {
-fprintf(stderr, Error: use only one of -eps and -form\n);
+ if ((doOrigPageSizes ? 1 : 0) +
+ (doEPS ? 1 : 0) +
+ (doForm ? 1 : 0) 1) {
+fprintf(stderr, Error: use only one of -origpagesizes,
Bug#630227: cups 1.4.6-8 does not support usblp anymore, breaking foo2zjs
An update of foo2zjs to do the firmware transfer without usblp is planned, at least for Debian and Ubuntu. I will create an appropriate package soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630228: foo2zjs: Firmware upload is not compatible with cups
On 06/12/2011 04:03 PM, Didier Raboud wrote: I'm hereby CC'ing the CUPS maintainers; opinions ? I know about that problem and I will update the firmware upload script in the foo2zjs package soon, so that it also works with libusb. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630228: Info received (Bug#630228: foo2zjs: Firmware upload is not compatible with cups)
The fix is simple. The firmware uploader script needs to determine whether usblp is loaded or not, and if it is not loaded and the CUPS filter /usr/lib/cups/filter/usb exists, it should run a command line like this (1020 replaced by actual model number): for uri in `sudo /usr/lib/cups/backend/usb | grep -i 'HP.*LaserJet.*1020' | grep -v FWVER | cut -d ' ' -f 2`; do echo $uri; sudo DEVICE_URI=$uri /usr/lib/cups/backend/usb 1 1 1 1 '' /lib/firmware/hp/sihp1020.dl; done This goes through all devices of the given model which do not have firmware loaded yet and load the firmware into them using the usb CUPS backend. As the usblp module is blacklisted by the CUPS package, this is sufficient to solve the problem. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630228: foo2zjs: Firmware upload is not compatible with cups
On 06/12/2011 05:29 PM, Roger Leigh wrote: Why is this not being done at a lower level, e.g. via udev or other existing hotplug mechanisms? Firmware-loading for /any/ device is not the remit of cups, and it's really not cups' call to disable any module loading. Do you know a tool which can send the firmware file to a raw libusb device, so that using the CUPS backend for this is not necessary? Note that upstream CUPS is only to be able to access the USB printers with one method, either usblp or libusb, not both. I suggested to use my patch for getting a hybrid usb backend upstream but Mike Sweet do not want to use it, he tells, usblp should be deprecated and only libusb should be used. libusb is also the better method for modern multi-function devices. Especially HP uses libusb in their hp CUPS backend. So for a better consistency it is better to use only libusb in CUPS environments. Therefore I want to deprecate usblp and switch software which still use it to use libusb. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630228: foo2zjs: Firmware upload is not compatible with cups
I have now updated the Ubuntu package (20110210dfsg-1ubuntu4) applying
the attached patch. The patch modifies the firmware upload script
hplj1000. It adds support for douing the firmware upload through the
usb backend of CUPS. This makes the upload independent of the presence
of usblp. It works also with the new libusb-based CUPS package.
Till
Index: foo2zjs-20110210dfsg/hplj1000
===
--- foo2zjs-20110210dfsg.orig/hplj1000 2011-06-14 16:30:59.331940282 +0200
+++ foo2zjs-20110210dfsg/hplj1000 2011-06-14 16:31:26.151976656 +0200
@@ -48,6 +48,12 @@
DEV=
#
+# Path to the USB CUPS backend. We use this backend to upload the firmware
+# into the printer when we are on a CUPS/libusb-based system.
+#
+USB_BACKEND=/usr/lib/cups/backend/usb
+
+#
# Directory to find downloadable HP firmware files sihp.dl
#
FWDIR=/lib/firmware/hp
@@ -195,7 +201,7 @@
esac
#
-# Procedure to load a single device with firmware
+# Procedures to load a single device with firmware
#
load1() {
_dev=$1
@@ -218,6 +224,33 @@
return 0
}
+load2() {
+fw=$FWDIR/sihp$FWMODEL.dl
+if [ ! -f $fw ]; then
+ log Missing HP LaserJet $MODEL firmware file $fw
+ log ...read foo2zjs installation instructions and run ./getweb $MODEL
+ return 1
+fi
+
+log loading HP LaserJet $MODEL firmware $fw to CUPS USB device ...
+# There is a timeout problem with udev and FC4, so spin it off.
+(
+ device_found=0
+ for uri in `$USB_BACKEND 2 /dev/null | grep -i 'HP.*LaserJet.*'$MODEL | grep -v FWVER | cut -d ' ' -f 2`; do
+ device_found=1
+ if DEVICE_URI=$uri /usr/lib/cups/backend/usb 1 1 1 1 '' $fw 2 /dev/null; then
+ log $uri... download successful.
+ else
+ log $uri... download failed.
+ fi
+ done
+ if [ $device_found = 0 ]; then
+ log ... no devices which need firmware found.
+ fi
+)
+return 0
+}
+
#
# OK, now download firmware to any printers that need it
#
@@ -226,6 +259,13 @@
# force downloading to a specific device
#
load1 $DEV
+elif [ -x $USB_BACKEND ]; then
+#
+# If we have CUPS installed, use the CUPS usb backend, as then we do
+# not need to care whether the system uses the usblp kernel module or
+# libusb
+#
+load2
elif [ -x $PRINTERID ]; then
#
# Sniff around for printers that need a firmware download
@@ -247,5 +287,5 @@
done
else
log HP LaserJet $MODEL firmware was not downloaded...
-log ...couldn't find $PRINTERID and DEV is not set
+log ...couldn't find $PRINTERID, DEV is not set, and CUPS not installed.
fi
Bug#630228: foo2zjs: Firmware upload is not compatible with cups
Small fix done on the patch ...
Till
Index: foo2zjs-20110210dfsg/hplj1000
===
--- foo2zjs-20110210dfsg.orig/hplj1000 2011-06-14 16:30:59.331940282 +0200
+++ foo2zjs-20110210dfsg/hplj1000 2011-06-14 16:31:26.151976656 +0200
@@ -48,6 +48,12 @@
DEV=
#
+# Path to the USB CUPS backend. We use this backend to upload the firmware
+# into the printer when we are on a CUPS/libusb-based system.
+#
+USB_BACKEND=/usr/lib/cups/backend/usb
+
+#
# Directory to find downloadable HP firmware files sihp.dl
#
FWDIR=/lib/firmware/hp
@@ -195,7 +201,7 @@
esac
#
-# Procedure to load a single device with firmware
+# Procedures to load a single device with firmware
#
load1() {
_dev=$1
@@ -218,6 +224,33 @@
return 0
}
+load2() {
+fw=$FWDIR/sihp$FWMODEL.dl
+if [ ! -f $fw ]; then
+ log Missing HP LaserJet $MODEL firmware file $fw
+ log ...read foo2zjs installation instructions and run ./getweb $MODEL
+ return 1
+fi
+
+log loading HP LaserJet $MODEL firmware $fw to CUPS USB device ...
+# There is a timeout problem with udev and FC4, so spin it off.
+(
+ device_found=0
+ for uri in `$USB_BACKEND 2 /dev/null | grep -i 'HP.*LaserJet.*'$MODEL | grep -v FWVER | cut -d ' ' -f 2`; do
+ device_found=1
+ if DEVICE_URI=$uri $USB_BACKEND 1 1 1 1 '' $fw 2 /dev/null; then
+ log $uri... download successful.
+ else
+ log $uri... download failed.
+ fi
+ done
+ if [ $device_found = 0 ]; then
+ log ... no devices which need firmware found.
+ fi
+)
+return 0
+}
+
#
# OK, now download firmware to any printers that need it
#
@@ -226,6 +259,13 @@
# force downloading to a specific device
#
load1 $DEV
+elif [ -x $USB_BACKEND ]; then
+#
+# If we have CUPS installed, use the CUPS usb backend, as then we do
+# not need to care whether the system uses the usblp kernel module or
+# libusb
+#
+load2
elif [ -x $PRINTERID ]; then
#
# Sniff around for printers that need a firmware download
@@ -247,5 +287,5 @@
done
else
log HP LaserJet $MODEL firmware was not downloaded...
-log ...couldn't find $PRINTERID and DEV is not set
+log ...couldn't find $PRINTERID, DEV is not set, and CUPS not installed.
fi
Bug#530600: Lexmark printer tray selection problem - Optra T series
Ruediger, can you attach the PPD files for the print queues with the bad behavior? The files are /etc/cups/ppd/queue name.ppd. Please attach the PPDs to your answer as separate uncompressed files. Thanks. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530600: Lexmark printer tray selection problem - Optra T series
I have updated the upstream BZR repository of foomatic-db and the OpenPrinting web site now replacing all the tray names in the manufacturer-independent InputSlot options by names without tray numbers. The tray numbering can differ from manufacturer to manufacturer. Ruediger has sent me the PPDs I asked for in private and they were all for the Foomatic/Postscript driver, which means that they are generic PostScript PPDs generated from the Foomatic XML files and not manufacturer-supplied PPDs. The new tray names will appear in the next foomatic-db package. For the time being use either PPD files supplied by Lexmark (highly recommended, in the openprinting-ppds package or on the OpenPrinting web site) or the PPD files of the Postscript driver entry on the OpenPrinting web site. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628573: hplip bonjour breaks for some hp printers (e.g. Photosmart D110a)
Can you report you problem to the HPLIP developers at HP, at https://launchpad.net/hplip/? Thanks. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613408: ghostscript: prints extra blank page
You can use the cupsfilter utility to run filter chains manually to find out which filter breaks things. Till On 02/15/2011 12:44 AM, Jonathan Nieder wrote: Hi Brian, brian m. carlson wrote: When I print a file with ghostscript 9, I always get a blank page printed first. Then my document prints normally. [...] The printer I am using is an Officejet 4500. I also see this problem with a Deskjet 5740. Both of these printers use the hplip/hpijs functionality, although one uses the full hplip (with the hp backend) and the other uses just the ppds (with the usb backend); these printers are on two different machines. While this is not terrible, it is inconvenient and quite irksome when I'm printing twenty copies of something. Cc-ing the hplip maintainers for ideas. What would be most useful for debugging: do you know any way to detect the blank page in the output (using gs -sOutputFile) without using an actual printer? With that information, it should be possible to bisect using the upstream ghostscript repo[1]. Thanks for reporting, Jonathan [1] git://git.ghostscript.com/ghostscript.git -- 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.
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#637978: cups: Please add a dpkg trigger to update PPDs on driver upgrades
Roger, my postinst scripts (which OdyX uses for his trigger solution) conserve the default settings by replacing the PPD files using lpadmin -m. They also support PPDs which do not exist physically but get generated on the fly (listing available PPDs with lpinfo -m and requesting them with lpadmin -m, no direct file system access is done). Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638277: libgs8 segfault : print jobs (recto/verso) stop after 2nd page
So it is an issue of the CUPS Raster output device of Ghostscript, cups. At Ghostscript upstream we have fixed several segfault bugs in the CUPS Raster output device (see upstream GIT log). Best is to upgrade to current Ghostscript 9.04 (best with cups/gdevcups.c replaced by the one from GIT master). If this is not possible, one should look into backporting some of these fixes. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639827: gstoraster segfaults on any attempt to print
Several segfaults in the CUPS Raster output device (this is used by gstoraster) and in Ghostscript in general got fixed in Ghostscript 9.04 and shortly after. The fixes are all contained in the Ghostscript package of Ubuntu Oneiric. I recommend to merge this package to Debian. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636801: argyll and libicc2 packages are based on same tarball, they should get merged
Package: argyll Version: 1.3.0-3 The packages argyll and libicc2 are both taking their source code from the upstream source tarball of Argyll. Having two (or more) different packages based on the same source code tarball one will easily get into a maintenance nightmare. If a security vulnerability shows up in the upstream code, all packages based on it need their upstream tarball be updated and rebuilt. One can easily forget one package and so the vulnerability stays in the forgotten package. I am introducing Color Management in Ubuntu and therefore I have updated the Argyll package to version 1.3.3 and also created a merged package (but not uploaded to Ubuntu). You can download it here: http://www.openprinting.org/download/tmp/argyll_1.3.3.orig.tar.gz http://www.openprinting.org/download/tmp/argyll_1.3.3-0ubuntu2.dsc http://www.openprinting.org/download/tmp/argyll_1.3.3-0ubuntu2.debian.tar.gz Problem is that the version number used for libicc is the API/ABI version number 2.12 which is much higher than the 1.3.3 of the upstream tarball. Ho should I proceed to make the resulting package being well accepted by Debian? Should I introduce an epoch? Or can a binary package have another version number than its source package? The mentioned package uses an epoch, but please tell me how to do it correctly. the merged package builds Argyll using the upstream Jam architecture, this makes maintenance much easier than with a packager-supplied autoconf/automake environment. Only libicc is built in a separate directory using the very simple autoconf/automake files from the former libicc2 package. This is done because the Jam environment has no functionality to create shared libraries. The package is a merger of Ubuntu packages, therefore it has Ubuntu release numbers, change them if you want to use this package in Debian. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637184: libjpeg6b linked with -Bsymbolic-functions, causing problems with HPLIP and pxljr
Package: libjpeg6b
Version: 6b1-2
In the last months Ubuntu users complained that their HP Color LaserJet
3500/3550/3600 does not print any more in the draft and normal printout
quality modes but still print in high quality mode. In the draft and
normal modes the printer uses JPEG compression for the image data, to
make the data transfer faster. The drivers, pxljr and hplip, use
libjpeg6b to implement the data compression, but as the printer's JPEG
format is not absolutely identical with the standard JPEG format, the
driver overrides certain symbols/functions of libjpeg with its own code
to implement the differences between standard JPEG and the printer's
JPEG. This is done in both the pxljr and hplip drivers.
Since some time LDFLAGS is set to -Wl,-Bsymbolic-functions by default
for package builds in Debian and this flag makes ashared library linked
with it disallowing the override of its symbols, breaking the pxljr and
hplip drivers, leading to the JPEG-based modes not working.
So as a fix, the upstream author of the pxljr driver, suggests to build
libjpeg without LDFLAGS being set to -Wl,-Bsymbolic-functions. I tried
it by preceeding the ./configure in debian/rules by LDFLAGS= and
this libjpeg made the two printer drivers working perfectly in draft and
normal quality modes.
I have attached a patch for the Ubuntu package showing how the fix looks
like. Can you please apply the same fix to the Debian package?
Till
diff -Nru libjpeg6b-6b1/debian/changelog libjpeg6b-6b1/debian/changelog
--- libjpeg6b-6b1/debian/changelog 2011-03-24 06:24:32.0 +0100
+++ libjpeg6b-6b1/debian/changelog 2011-08-08 19:57:41.0 +0200
@@ -1,3 +1,11 @@
+libjpeg6b (6b1-1ubuntu2) oneiric; urgency=low
+
+ * debian/rules: Remove -Bsymbolic-functions from LDFLAGS, as this flag
+breaks the libjpeg use by HPLIP and pxljr, in both cases for printing
+on the HP Color LaserJet 3500/3550/3600 (LP: #777670).
+
+ -- Till Kamppeter till.kamppe...@gmail.com Mon, 8 Aug 2011 19:57:23 +0200
+
libjpeg6b (6b1-1ubuntu1) natty; urgency=low
* Enable multiarch build (LP: #733501)
diff -Nru libjpeg6b-6b1/debian/rules libjpeg6b-6b1/debian/rules
--- libjpeg6b-6b1/debian/rules 2011-03-24 06:24:00.0 +0100
+++ libjpeg6b-6b1/debian/rules 2011-08-08 20:09:36.0 +0200
@@ -20,7 +20,7 @@
build: build-stamp
build-stamp:
dh_testdir
- ./configure --prefix=/usr --mandir=/usr/share/man \
+ LDFLAGS= ./configure --prefix=/usr --mandir=/usr/share/man \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--enable-static --enable-shared --enable-maxmem=1024 \
--build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
Bug#637184: libjpeg6b linked with -Bsymbolic-functions, causing problems with HPLIP and pxljr
Martin Pitt asked me to report the bug also to Debian. He told the situation there is the same. HPLIP is indeed build-depending on libjpeg-dev and not on libjpeg62-dev. I for got that I did this change, as I only checked binary package dependencies and it seems that in Ubuntu the libjpeg-dev has still pulled libjpeg62-dev. If simply building HPLIP against the new libjpeg would also fix the printing problem would be great. Someone should test that. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627770: foomatic-db-engine doesn't work with foomatic-db-compressed-ppds
The concept is the following: The recommended Foomatic setup for end users (and default Foomatic setup on Ubuntu) is foomatic-db-compressed-ppds and foomatic-rip. The pre-built and compressed PPD files in foomatic-db-compressed-ppds take much less space than the Foomatic XML data of foomatic-db and they get also delivered much more quickly on requests by CUPS than the PPD files generated from the XML data by foomatic-db-engine on demand. foomatic-db-engine gets a developer package (like gcc) then. It is only needed to build compressed PPD repositories from Foomatic XML data, so it is only needed to build packages. foomatic-db-engine also makes sense when foomatic-db is not installed, as in the package build scenario one usually has the Foomatic XML data from which one builds the PPD files at another than the usual place, like in the package's source tree or in a temporary directory. This is the case because one builds from the Foomatic data which the package ships or one mixes data from foomatic-db with data from the package, which a package build cannot do in /usr/share/foomatic. To do so, one sets the environment variable FOOMATICDB pointing to the desired XML database and then one calls the tools of foomatic-db-engine. Therefore we only suggest foomatic-db and do not recommend or even require it. The Provides: foomatic-db was added to foomatic-db-compressed-ppds for the transition of Ubuntu from foomatic-db/foomatic-db-engine to foomatic-db-compressed-ppds, together with Conflicts: foomatic-db; Replaces: foomatic-db. In the Google Summer of Code another approach of using the OpenPrinting database (foomatic-db) will get added: The XMLs will be converted to an SQLite database. This is more flexible than the compressed PPDs as one can easily modify the data in the SQL databse, but on the other side it is probably not so compact and fast as the compressed PPDs. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627542: foo2zjs: Duplex printing option gone
Sam, does your printer have a duplex unit? Or was the duplex option in the PPD files only for activating a manual duplex function? In the latter case the manual duplex function in the driver was replaced by a GUI tool (gnome-manual-duplex) which helps the user to get through the steps and to turn over the printer pages correctly. gnome-manual-duplex is not packaged yet. It needs to be investigated how well it works, whether it supports only local printing or also printing through the network, does not have any security issues, ... and if all is OK it should be packaged. Re-introducing manual duplex by a patch to the PPD file perhaps will not work as the code for manual duplex can be removed from the driver. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634030: hplip: Please Build-Depends on libjpeg-dev, not libjpeg62-dev
I have updated the SVN repository of HPLIP now. So it needs only someone to upload the current state. I have tested and after the change it also builds correctly under Ubuntu, so that the Debian and Ubuntu packages can be kept identical. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635261: Possible solution: Add -dNOINTERPOLATE to Ghostscript command line
See my last comment in the Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/foomatic-db/+bug/690116/comments/5 Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679117: printer-driver-ptouch: Incorrect Margins for PT9500PC and PT9800PCN
Thank you very much for the patch. In your patch you write Attention: Not tested on other printers. and indeed your patch changes code which affects all supported printers, not only the two models with which you were suffering the problem. This can easily break things on the other printers, assuming that most supported printers work correctly with the original code. If you are not sure that the change works for all printers you should do it in a way that it only applies if the printer is one of the models for which you have made the change. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631025: cups: change default ErrorPolicy for network printers
CUPS has the retry-job error policy as default only for Ubuntu and there reports like yours never showed up, and also no bug reports for asking to return to the original stop-printer by default. pitti, should we activate the patch to switch to the retry-job error policy as default also for Debian? Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631025: cups: change default ErrorPolicy for network printers
On 06/21/2012 05:41 AM, Martin Pitt wrote: Till Kamppeter [2012-06-20 18:17 +0200]: CUPS has the retry-job error policy as default only for Ubuntu and there reports like yours never showed up, and also no bug reports for asking to return to the original stop-printer by default. pitti, should we activate the patch to switch to the retry-job error policy as default also for Debian? I have no strong opinion about this. I would be a bit hesitant to change it so close to the Wheezy final freeze, but if there are good reasons for it and some other Debian users agree, sure. Why are there two different defaults for Debian and Ubuntu. What are the motivations in each of the distros? I prefer retry-job as it confuses unexperienced users less. In addition, the backends are badly designed or too enterprise-oriented, making queues getting stopped on temporary failures which users can easily fix, like printer not turned on, cable not plugged in, paper/toner empty, bad per-job option settings. If queues are stopped by failures then they only should get stopped by permanent failures, like queue being set up with wrong driver or wrong device URI, filter required by PPD not installed, not executable, or segfaulting. The default configuration of CUPS (and every other subsystem) should be optimized for desktop/small network users, as these are the ones who do know less about configuring and most need our help. Enterprise system administrators have more ease to change the configuration and can make queues getting stopped when the toner runs out if thwy want it. Therefore I suggest that, in both Debian and Ubuntu 1. ErrorPolicy is et to retry-job 2. CUPS listens to remote printer broadcasts by default Also Debian and Ubuntu should use the same defaults. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673289: cups-filters: PID xxxxx (/usr/lib/cups/filter/texttopdf) crashed on signal 6.
Paul, thank you for reporting the bug. Tobias, can you have a look into this? The crash is most probably caused by a font problem. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055
For me it looks OK, I would apply it upstream. Tobias, WDYT? Is this patch on texttopdf OK? Perhaps it also fixes bug 673289. Till On 05/18/2012 03:51 PM, Didier Raboud wrote: tags 670055 + pending thanks Dear Till and Martin, I've prepared an upload for cups-filters (versioned as 1.0.18-2) with Fabian's patch and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer or reschedule it to let it go as is. Best regards, OdyX P.S. I have pushed the change to the packaging repository. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055
On 05/22/2012 01:39 PM, Tobias Hoffmann wrote: Hmm, I don't really know, but the cups-filters package has a bugtracker at https://bugs.linuxfoundation.org/ (under the OpenPrinting product). But just another debian bug would work equally well ... Till? Tobias, if this needs to be fixed in the texttopdf filter a bug on https://bugs.linuxfoundation.org/ can be filed. If it is a problem of Debian's packaging or Debian shipping a broken font or not shipping a required font then open a Debian bug. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055
On 05/22/2012 03:11 PM, Tobias Hoffmann wrote: Well, it's still not clear, who should fix what: 1. cups-pdf should probably announce that it can not only process PS, but also PDF. I'm not sure if the current cups-filter architecture handles this case well. This bug would be one of cups-pdf or cups-filter(?). This is a cups-pdf problem. I have even fixed it once by doing some slight changes on cups-pdf, making the PPD file accepting both PDF and PostScript as input and modifying the backend script to skip Ghostscript if the input is already PDF. Upstream did not accept this patch as one can modify the output by a variety of options in the config file and these options are implemented via Ghostscript. I suggest then to do a slightly different approach, only skipping Ghostscript if the settings in the config file are the default settings and otherwise using Ghostscript also with PDF input, simply feeding PDF into Ghostscript. See debian/patches/70_cups-pdf_support-pdf-workflow.patch in cups-pdf 2.5.0-17 on https://launchpad.net/ubuntu/+source/cups-pdf/2.5.0-17 2. It's unclear to me what the policy regarding pdftops is wrt. to using popper vs. ghostscript as converting agent. gs generates Type 3 (which causes problems), poppler does not. This can be fixed in pdftops, i.e. cups-filter, (use poppler tools in this case), or ghostscript (don't generate Type 3 -- there might be some commandline switches) For pdftops I was always tending to use Ghostscript as Ghostscript has once better color management and is designed more with printing in mind. At the release of Ubuntu Precise (12.04) I have found out that Ghostscript's PS output has problems with several PostScript printers due to bugs in the printer's PS interpreters. I added some workarounds to the pdftops filter for that. Which PostScript consumers do not like Type 3 fonts? Should I make Ghostscript only sending Type 2 fonts? Chris, is there a command line switch to make Ghostscript's ps2write device only sending Type 2 fonts? 3. The issue, that the Type 3 bounding boxes generated by ghostscript are deemed bad by poppler/evince. The experts from ghostscript and poppler have to determine who is wrong (it might even be caused by the original font file). Therefore this is either a poppler/evince, ghostscript or font bug. Chris, can it be that there is a bug in Ghostscript? Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681495: printer-driver-ptouch: rastertoptch installed in directory that's not in cups' PATH
We have fixed this in Ubuntu already. See: https://launchpad.net/ubuntu/+source/ptouch-driver/+changelog http://launchpadlibrarian.net/106473938/ptouch-driver_1.3-3_1.3-3ubuntu0.1.diff.gz Please back-sync this package to Debian. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681851: escputil: requires module usblp which is blacklisted by CUPS
In the newest CUPS package (1.5.3-4) we have lifted the blacklisting again (solving the USB problems with a new USB backend). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682078: hplip: Draft quality makes hpcups failed for Deskjet D2660
This problem of having one quality level not working looks most like a fault inside the driver. Please report this problem upstream on http://launchpad.net/hplip/ Then the HPLIP developers at HP will get aware of this problem. Please tell there everything which you told here and also post the /var/log/cups/error_log and the hp-check output, as you did here. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611993: [ghostscript] Could reproduce with newer version
I could also reproduce the problem with Ghostscript 9.05 on Ubuntu Quantal. Therefore I have forwarded the problem upstream: http://bugs.ghostscript.com/show_bug.cgi?id=693205 Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663868: Blacklisting usblp helps
Please remove the blacklisting for usblp, run # modprobe usblp set CUPS into debug mode: # cupsctl LogLevel=debug and then turn off and turn on the printer again. Does it load its firmware? If not, attach your /var/log/cups/error_log file. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649991: [Pkg-hpijs-devel] Bug#649991: Please rename the hplip packages to the printer-driver- convention
Thanks for the patch. The patch is not complete. The hplip-data binary package contains the PPD files for HP's PostScript printers, so the hplip package is also a printer driver. The PPD updater is in hplip (a packaging bug). So there should be a new binary package named printer-driver-hp-postscript, containing these PPDs (current file /usr/lib/cups/driver/hplip, should then be /usr/lib/cups/driver/hp-postscript) and the corresponding PPD updater. The hpijs-ppds package is not needed by CUPS as CUPS auto-generates the PPDs based on the .drv file in the hpijs binary package. hpijs-ppds is only needed for non-CUPS spoolers which cannot cope with a .drv file. WDYT, should hpijs-ppds also be renamed to printer-driver-...? Should it keep its name? Or should it get dropped? Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649991: [Pkg-hpijs-devel] Bug#649991: Please rename the hplip packages to the printer-driver- convention
On 01/05/2012 01:36 PM, Didier Raboud wrote: On Thu, 05 Jan 2012 13:16:15 +0100, Till Kamppeter wrote: I based my patch on the summary I did both there [0] and when filing the bug [1], both which didn't get reactions. [0] http://lists.debian.org/debian-printing/2011/11/msg00017.html [1] http://lists.debian.org/debian-printing/2011/11/msg00050.html My main question is does hplip serve as printer driver for CUPS?, as the main reasoning behind the printer-driver-* naming scheme is to have them all installed in a standard installation involving cups. A binary package containing PPDs for PostScript printers is a printer driver, the driver for the PostScript mode of these printers. Note that a PostScript printer driver usually consists of only PPD files. A printer driver package has to contain at least PPDs (the files itself, the PPDs pyppd-compressed, or a PPD generator, either an executable in /usr/lib/cups/driver/ or a .drv file in /usr/share/cups/drv/) and the PPD updater for these PPDs (to update PPDs of existing queues, either in postinst script or a file in /usr/share/cups/ppd-updaters/). In addition, it must contain all filters specified in the cupsFilter lines of the PPDs and their dependencies or depend on the packages containing these filters. My suggestion is to create a new binary package named printer-driver-postscript-hp containing the pyppd-compressed PostScript PPD files (move from hplip-data) plus the PPD updater (move from hplip) to get consistency. The driver name for this new package is Postscript-HP (to be consistent with PostScript driver entry names on OpenPrinting) and not hplip any more, so the files should have appropriate names. printer-driver-postscript-hp should recommend the hplip package, as hplip gives extra functionality (like toner level check) to the PostScript printers but the printers work also without the hplip package installed. There are no PostScript PPDs with valid cupsFilter lines requiring filter executables from the hplip package. (As a side note, I think we'll end up having two classes of printer-driver-* packages: the ones installed trough recommends and the ones only suggested by printer-driver-all, but that's yet to be discussed.) So there should be a new binary package named printer-driver-hp-postscript, containing these PPDs (current file /usr/lib/cups/driver/hplip, should then be /usr/lib/cups/driver/hp-postscript) and the corresponding PPD updater. Sounds sane, Lets name the new driver Postscript-HP and the package printer-driver-postscript-hp, to be consistent with OpenPrinting. The hpijs-ppds package is not needed by CUPS as CUPS auto-generates the PPDs based on the .drv file in the hpijs binary package. hpijs-ppds is only needed for non-CUPS spoolers which cannot cope with a .drv file. WDYT, should hpijs-ppds also be renamed to printer-driver-...? Should it keep its name? Or should it get dropped? Certainly not printer-driver-*, and I don't see a value in dropping it, hence let's keep it as is. OK, the hpijs-ppds package is not part of the standard CUPS printing environment, so we do not rename it. P.S. Do you want me to provide a new patch or will you work on it (I don't mind preparing it, just say.)? OK, please provide a new patch. Thanks you very much. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682426: cups: filter gs takes several minutes consuming 100 % of CPU
On 10/22/2012 06:22 PM, Didier 'OdyX' Raboud wrote: Le lundi, 22 octobre 2012 15.51:19, Paul Menzel a écrit : Didier, thank you for following up on the report. Today I hit this problem again – unfortunately when being in a hurry. It looks like on a new installed system, CUPS is not affected as it does not use the gs filter by default anymore(?). Well, CUPS now supposedly uses the PDF workflow and avoids converting PDF's to PS'es when unnecessary. Till will correct me if I'm wrong. :) Yes, that is the case. Usually PDF is only converted into PS if the printer is a PS printer or the driver requires PS input (like foo2zjs). Additionally bug #664538 [2] seems to deal with the same problem. Brian kindly followed up, mentioning too that it has to do with the gs filter in cups-filters and that pdftops might work. Well, the pdftops filter calls gs in Wheezy, as far as I can see. At least in the newest upstream version of cups-filters one can switch the filter to use pdftops from Poppler. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682426: cups: filter gs takes several minutes consuming 100 % of CPU
The real bug here is a Ghostscript bug. Ghostscript is not able to render a given input file in a reasonable time. This will be best fixed by the upstream developers of Ghostscript. They will need to reproduce the bug without CUPS, therefore we need the original input file and how CUPS has processed it. To obtain this information follow the instructions of the sections CUPS error_log and Capturing print job data on https://wiki.ubuntu.com/DebuggingPrintingProblems. These instructions are originally made for Ubuntu, but the CUPS package is identical in Debian and Ubuntu, so they should also work in Debian. Note that instead of running a command as root by preceding it with sudo, like sudo start cups, run the command (without preceded sudo) in a second terminal window where you have switched to root via su -. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664031: Inkscape
Note that the printing of Inkscape currently does not work. See: https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/975972 Inkscape sends pages with zero width and zero height page size setting. Workaround is always to print out of the page preview of Inkscape. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649991: [Pkg-hpijs-devel] Bug#649991: Please rename the hplip packages to the printer-driver- convention
OdyX, thank you for the patch. I have reviewed it and applied it now to the SVN repository of HPLIP and uploaded the new package to Ubuntu (Precise). Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662025: foomatic-filters: Fails to print if 4.0.12-1 or 4.0.13-1 is installed
I have checked your error_log and it shows one job which has successfully completed. I assume that this is the job which did not print for you. First, a reasonable amount of data gets sent to the printer but it does not make the printer printing something. Second, your attached error_log has only the following part which looks strange: -- D [08/Mar/2012:21:04:00 +0100] [Job 233] Options from the PPD file: D [08/Mar/2012:21:04:00 +0100] [Job 233] D [08/Mar/2012:21:04:00 +0100] [Job 233] D [08/Mar/2012:21:04:00 +0100] [Job 233] D [08/Mar/2012:21:04:00 +0100] [Job 233] File: STDIN D [08/Mar/2012:21:04:00 +0100] [Job 233] D [08/Mar/2012:21:04:00 +0100] [Job 233] -- This makes the impression that foomatic-rip did not read any options from the PPD file. Please run the command ls -l /etc/cups/ppd/FS-1020D.ppd and attach your /etc/cups/ppd/FS-1020D.ppd file. Thanks. Till On 03/08/2012 09:19 PM, Helge Kreutzmann wrote: Hello, On Mon, Mar 05, 2012 at 12:32:02PM +0100, Till Kamppeter wrote: We need some more information about your problem. First, can you tell us which printer (manufacturer/model), connection type (USB, Kyocera Ecosys FS-1020D, now connected via USB (used to be parallel, I still have the conection wired to the old (shut down) machine). Parallel, USB-Parallel adapter, network, ...), driver you are using? Driver?? None specifilly. Or do you men ppd file? Can you also follow the instructions of the sections CUPS error_log and Capturing print job data on https://wiki.ubuntu.com/DebuggingPrintingProblems. The site is for Ubuntu, but the steps of the mentioned sections also work under Debian. If sudocommand does not work or if some administrative command of CUPS does not work, run the command in a second terminal window where you get root via su -, without the sudo in the beginning. Ok. Note that we need this information to be able to fix the bug. Fine. a) There is no »ubuntu-bug« within Debian main (testing). b) apport-collect does not exist neither c) Output of printdebuginfo: == System information == Ubuntu Release : testing (wheezy) Desktop Environment: none Architecture : x86_64 Kernel : 3.2.9sneo.01-grsec Locale : LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8, LC_PAPER=de_DE.UTF-8 /etc/papersize : a4 == Configured printers == FS-1020D: Kyocera FS-1020D Foomatic/Postscript Kyocera-neu: Kyocera Mita FS-1020D Kyocera: Kyocera Mita FS-1020D Kyocera_FS-1020D: Kyocera Mita FS-1020D device for FS-1020D: usb://Kyocera/FS-1020D?serial=XAX5560374 device for Kyocera_FS-1020D: usb://Kyocera/FS-1020D?serial=XAX5560374 == Installed versions of important printing packages == ii cups-ppdc1.5.2-5 Common UNIX Printing System(tm) - PPD manipulation utilities ii foomatic-filters 4.0.12-1 OpenPrinting printer support - filters ii gs-cjk-resource 1.20100103-3 Resource files for gs-cjk, ghostscript CJK-TrueType extension ii hp-ppd 0.9-0.2 HP Postscript Printer Definition (PPD) files ii hpijs3.11.12-2 transitional dummy package for hpijs printer driver ii libcupsppdc1 1.5.2-5 Common UNIX Printing System(tm) - PPD manipulation library ii printer-driver-gutenprint5.2.7-5 printer drivers for CUPS ii system-config-printer1.3.7-3 graphical interface to configure the printing system Created with printingbuginfo script v1.5 (https://wiki.ubuntu.com/PrintingBugInfoScript) Thu, 08 Mar 2012 20:54:48 +0100 d) 1. Connected, powered on (on not working foomatic version) 2. root@sneo:/tmp# lsmod | grep usb usblp 12593 0 usbhid 30418 0 3.-5: tail -f /var/log/syslog Mar 8 20:56:27 sneo kernel: usblp0: removed Mar 8 20:56:46 sneo kernel: usb 4-5.2: new full-speed USB device number 4 using ohci_hcd Mar 8 20:56:46 sneo kernel: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x0482 pid 0x000E Mar 8 20:56:46 sneo mtp-probe: checking bus 4, device 4: /sys/devices/pci:00/:00:12.0/usb4/4-5/4-5.2 Mar 8 20:56:46 sneo mtp-probe: bus: 4, device: 4 was not an MTP device Mar 8 20:56:47 sneo udev-configure-printer: add /devices/pci:00/:00:12.0/usb4/4-5/4-5.2/4-5.2:1.0 Mar 8 20:56:47 sneo udev-configure-printer: device devpath is /devices/pci:00/:00:12.0/usb4/4-5/4-5.2 Mar 8 20:56:47 sneo udev-configure-printer: Device already handled Mar 8 20:56:47 sneo udev-configure-printer: add /devices/pci:00/:00:12.0/usb4/4-5/4-5.2/4-5.2:1.0
Bug#662025: foomatic-filters: Fails to print if 4.0.12-1 or 4.0.13-1 is installed
I do not see any problem with your PPD. I can print with it on my HP PostScript printers without problem. Can you print with the manufacturer-supplied PPD file? The manufacturer-supplied PPD sends some PJL directives to the printer before sending the PostScript code. Perhaps the Kyocera printers need this. Till On 03/09/2012 04:47 PM, Helge Kreutzmann wrote: Hello Till, On Thu, Mar 08, 2012 at 10:22:33PM +0100, Till Kamppeter wrote: I have checked your error_log and it shows one job which has successfully completed. I assume that this is the job which did not print for you. Yes. First, a reasonable amount of data gets sent to the printer but it does not make the printer printing something. Second, your attached error_log has only the following part which looks strange: -- D [08/Mar/2012:21:04:00 +0100] [Job 233] Options from the PPD file: D [08/Mar/2012:21:04:00 +0100] [Job 233] D [08/Mar/2012:21:04:00 +0100] [Job 233] D [08/Mar/2012:21:04:00 +0100] [Job 233] D [08/Mar/2012:21:04:00 +0100] [Job 233] File:STDIN D [08/Mar/2012:21:04:00 +0100] [Job 233] D [08/Mar/2012:21:04:00 +0100] [Job 233] -- This makes the impression that foomatic-rip did not read any options from the PPD file. Please run the command ls -l /etc/cups/ppd/FS-1020D.ppd root@sneo:~# ls -l /etc/cups/ppd/FS-1020D.ppd -rw-r--r-- 1 root root 9777 Aug 28 2011 /etc/cups/ppd/FS-1020D.ppd root@sneo:~# ls -l /etc/cups/ppd/* -rw-r--r-- 1 root root 9777 Aug 28 2011 /etc/cups/ppd/FS-1020D.ppd -rw-r--r-- 1 root root33401 Aug 28 2011 /etc/cups/ppd/Kyocera_FS-1020D.ppd -rw-r--r-- 1 root lpadmin 33421 Okt 15 2008 /etc/cups/ppd/Kyocera-neu.ppd -rw-r--r-- 1 root lpadmin 33421 Aug 4 2005 /etc/cups/ppd/Kyocera.ppd and attach your /etc/cups/ppd/FS-1020D.ppd file. Done. Thanks. Till On 03/08/2012 09:19 PM, Helge Kreutzmann wrote: Hello, On Mon, Mar 05, 2012 at 12:32:02PM +0100, Till Kamppeter wrote: We need some more information about your problem. First, can you tell us which printer (manufacturer/model), connection type (USB, Kyocera Ecosys FS-1020D, now connected via USB (used to be parallel, I still have the conection wired to the old (shut down) machine). Parallel, USB-Parallel adapter, network, ...), driver you are using? Driver?? None specifilly. Or do you men ppd file? Can you also follow the instructions of the sections CUPS error_log and Capturing print job data on https://wiki.ubuntu.com/DebuggingPrintingProblems. The site is for Ubuntu, but the steps of the mentioned sections also work under Debian. If sudocommand does not work or if some administrative command of CUPS does not work, run the command in a second terminal window where you get root via su -, without the sudo in the beginning. Ok. Note that we need this information to be able to fix the bug. Fine. a) There is no »ubuntu-bug« within Debian main (testing). b) apport-collect does not exist neither c) Output of printdebuginfo: == System information == Ubuntu Release : testing (wheezy) Desktop Environment: none Architecture : x86_64 Kernel : 3.2.9sneo.01-grsec Locale : LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8, LC_PAPER=de_DE.UTF-8 /etc/papersize : a4 == Configured printers == FS-1020D: Kyocera FS-1020D Foomatic/Postscript Kyocera-neu: Kyocera Mita FS-1020D Kyocera: Kyocera Mita FS-1020D Kyocera_FS-1020D: Kyocera Mita FS-1020D device for FS-1020D: usb://Kyocera/FS-1020D?serial=XAX5560374 device for Kyocera_FS-1020D: usb://Kyocera/FS-1020D?serial=XAX5560374 == Installed versions of important printing packages == ii cups-ppdc1.5.2-5 Common UNIX Printing System(tm) - PPD manipulation utilities ii foomatic-filters 4.0.12-1 OpenPrinting printer support - filters ii gs-cjk-resource 1.20100103-3 Resource files for gs-cjk, ghostscript CJK-TrueType extension ii hp-ppd 0.9-0.2 HP Postscript Printer Definition (PPD) files ii hpijs3.11.12-2 transitional dummy package for hpijs printer driver ii libcupsppdc1 1.5.2-5 Common UNIX Printing System(tm) - PPD manipulation library ii printer-driver-gutenprint5.2.7-5 printer drivers for CUPS ii system-config-printer1.3.7-3 graphical interface to configure the printing system Created with printingbuginfo script v1.5 (https://wiki.ubuntu.com/PrintingBugInfoScript) Thu, 08 Mar 2012 20:54:48 +0100 d) 1. Connected, powered on (on not working foomatic version) 2. root@sneo:/tmp# lsmod | grep usb usblp 12593 0 usbhid
Bug#662025: foomatic-filters: Fails to print if 4.0.12-1 or 4.0.13-1 is installed
Please set up a print queue with this PPD: http://www.openprinting.org/ppd-o-matic.php?driver=Postscript-Kyoceraprinter=Kyocera-FS-1020D Can you print then? Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663192: [Pkg-cups-devel] Bug#663192: cups-filters: Please add support for embedding of Opentype fonts
Patches are welcome. Can OpenType be embedded in a PDF? Or would we need to convert such a font? Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663192: [Pkg-cups-devel] Bug#663192: cups-filters: Please add support for embedding of Opentype fonts
There are not really time constraints. For Ubuntu Precise 12.04 cups-filters 1.0.5 with texttopdf being fully fontconfig-based is enough. Precise comes with suitable TTF fonts. Currently, the change is more thought for upstream to be prepared for the first distros which drop TTF fonts. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662025: foomatic-filters: Fails to print if 4.0.12-1 or 4.0.13-1 is installed
Note that the new PPD I suggested does not use foomatic-rip, it should work (or not work) independent of the foomatic-filters version installed. The piece of error_log you pasted showed only some USB timeouts. Whether they actually prevent your printer from printing is not known. To determine whether valid PostScript data reaches the backend, you need to clone your print queues into queues pointing into a file. Run the command cupsctl FileDevice=yes then do for each print queue: lpadmin -p queue-file -E -v file:/tmp/printout-queue -P /etc/cups/ppd/queue.ppd Replacs queue by the actual queue name. Print into the clone queues, always the same input file, a file which showed the problem for you. Make the resulting files readable for normal users: chmod 777 /tmp/printout* Examine the files to see whether they contain valid PostScript, have PJL commands in the beginning, ... Note that if they have PJL commands in the beginning, evince cannot display their PostScript part on the screen but gv can. Are the files OK or are they already without printable data? If they contain printable data, print them unfiltered to the original queues: lpr -P queue -oraw /tmp/printout-queue For the foomatic-filters case (Foomatic/Postscript queue), do this with both the old and the new foomatic-filters with the same input file and attach the /tmp/printout-queue files once the one which prints of the old foomatic-filters and second, the one which does not print of the new foomatic-filters. On 03/11/2012 10:32 AM, Helge Kreutzmann wrote: Hello Till, On Fri, Mar 09, 2012 at 08:05:20PM +0100, Till Kamppeter wrote: Please set up a print queue with this PPD: http://www.openprinting.org/ppd-o-matic.php?driver=Postscript-Kyoceraprinter=Kyocera-FS-1020D Did so. The PPD seems to be the English version of one I already have installed (a Diff confirms this, only some terms are translated). Can you print then? No, not with current foomatic-filters: ii foomatic-filters 4.0.12-1 OpenPrinting printer support - filters Error log excerpt (lpstat of that user is still showing the job, btw., lpq does not show anything): D [11/Mar/2012:10:05:06 +0100] cupsdReadClient: 16 POST / HTTP/1.1 D [11/Mar/2012:10:05:06 +0100] cupsdSetBusyState: newbusy=Active clients, printing jobs, and dirty files, busy=Printing jobs and dirty files D [11/Mar/2012:10:05:06 +0100] cupsdAuthorize: No authentication data provided. D [11/Mar/2012:10:05:06 +0100] cupsdReadClient: 16 1.1 Get-Jobs 1 D [11/Mar/2012:10:05:06 +0100] Get-Jobs ipp://localhost/ D [11/Mar/2012:10:05:06 +0100] Returning IPP successful-ok for Get-Jobs (ipp://localhost/) from localhost D [11/Mar/2012:10:05:06 +0100] cupsdSetBusyState: newbusy=Printing jobs and dirty files, busy=Active clients, printing jobs, and dirty files D [11/Mar/2012:10:05:06 +0100] cupsdReadClient: 16 WAITING Closing on EOF D [11/Mar/2012:10:05:06 +0100] cupsdCloseClient: 16 D [11/Mar/2012:10:05:06 +0100] cupsdSetBusyState: newbusy=Printing jobs and dirty files, busy=Printing jobs and dirty files I [11/Mar/2012:10:05:09 +0100] Saving job.cache... D [11/Mar/2012:10:05:09 +0100] cupsdSetBusyState: newbusy=Printing jobs, busy=Printing jobs and dirty files D [11/Mar/2012:10:05:15 +0100] [Job 237] Wrote 8192 bytes of print data... D [11/Mar/2012:10:05:15 +0100] [Job 237] Read 8192 bytes of print data... D [11/Mar/2012:10:05:23 +0100] cupsdAcceptClient: 16 from localhost (Domain) D [11/Mar/2012:10:05:23 +0100] cupsdReadClient: 16 POST / HTTP/1.1 D [11/Mar/2012:10:05:23 +0100] cupsdSetBusyState: newbusy=Active clients and printing jobs, busy=Printing jobs D [11/Mar/2012:10:05:23 +0100] cupsdAuthorize: No authentication data provided. D [11/Mar/2012:10:05:23 +0100] cupsdReadClient: 16 1.1 Get-Jobs 1 D [11/Mar/2012:10:05:23 +0100] Get-Jobs ipp://localhost/ D [11/Mar/2012:10:05:23 +0100] Returning IPP successful-ok for Get-Jobs (ipp://localhost/) from localhost D [11/Mar/2012:10:05:23 +0100] cupsdSetBusyState: newbusy=Printing jobs, busy=Active clients and printing jobs D [11/Mar/2012:10:05:23 +0100] cupsdReadClient: 16 WAITING Closing on EOF D [11/Mar/2012:10:05:23 +0100] cupsdCloseClient: 16 D [11/Mar/2012:10:05:23 +0100] cupsdSetBusyState: newbusy=Printing jobs, busy=Printing jobs D [11/Mar/2012:10:05:26 +0100] cupsdAcceptClient: 16 from localhost (Domain) D [11/Mar/2012:10:05:26 +0100] cupsdReadClient: 16 POST / HTTP/1.1 D [11/Mar/2012:10:05:26 +0100] cupsdSetBusyState: newbusy=Active clients and printing jobs, busy=Printing jobs D [11/Mar/2012:10:05:26 +0100] cupsdAuthorize: No authentication data provided. D [11/Mar/2012:10:05:26 +0100] cupsdReadClient: 16 1.1 Get-Jobs 1 D [11/Mar/2012:10:05:26 +0100] Get-Jobs ipp://localhost/ D [11/Mar/2012:10:05:26 +0100] Returning IPP successful-ok for Get-Jobs (ipp://localhost/) from localhost D [11/Mar/2012:10:05:26 +0100] cupsdSetBusyState: newbusy=Printing jobs, busy
Bug#663554: Nags me to install proprietary plug-in although printer works
In the SVN repository for the Debian packaging of HPLIP I have already deactivated HPLIP's automatic pop-up for the firmware installation as it happens with every LaserJet printer (also my PostScript printers which for sure work without plugin). So the next HPLIP package in Debian will have the problem solved. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663554: Nags me to install proprietary plug-in although printer works
Quick workaround: Remove the file /lib/udev/rules.d/86-hpmud_plugin.rules Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663564: [Pkg-cups-devel] Bug#663564: Acknowledgement (cups-filters: 'make clean' leaves some object files over)
Fabian, thank you for the patch. I have applied your second patch to the upstream BZR repository now. It will be incluced from cups-filters 1.0.6 on. Till On 03/12/2012 10:53 AM, Fabian Greffrath wrote: An alternative approach, maybe less intrusive: Instead of touching Makedefs, define the correct actual dependency in the top-level Makefile. This will cause configure to be run when 'make distclean' is called twice in a row, which is a bit tedious, but at least it's not a hack anymore but a solution. ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660420: Some Postscript printer drivers (Kyocera, Brother, maybe others) do not work anymore
This bug I have fixed with cups-filters 1.0.5-1. This version inserts code snippets into PostScript output for Kyocers and Brother PostScript printers to work around the incompatibilities/PS interpreter bugs. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660348: Bug#660420: cups: Prints one blank sheet regardless of document size (Brother HL-5240)
This bug I have fixed with cups-filters 1.0.5-1. This version inserts code snippets into PostScript output for Kyocers and Brother PostScript printers to work around the incompatibilities/PS interpreter bugs. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
