Processed: tagging 716830
Processing commands for cont...@bugs.debian.org: > tags 716830 + upstream Bug #716830 [printer-driver-hpcups] Wrong colors are printed on arm device using hpcups Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 716830: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716830 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.137375729831923.transcr...@bugs.debian.org
Bug#716867: cups-client: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Package: cups-client Version: 1.6.2-10 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + cups Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: wheezy -> jessie For /usr/share/doc/PACKAGE this may not be problematic as long as both packages are installed, ship byte-for-byte identical files and are upgraded in lockstep. But once one of the involved packages gets removed, the other one will lose its documentation files, too, including the copyright file, which is a violation of Policy 12.5: http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile For other overwritten locations anything interesting may happen. Note that dpkg intentionally does not replace directories with symlinks and vice versa, you need the maintainer scripts to do this. See in particular the end of point 4 in http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase For switching from a symlink to a directory, the *preinst* script should do something like this: DOCDIR=/usr/share/doc/@@PACKAGE@@ if [ -L $DOCDIR ]; then rm $DOCDIR fi >From the attached log (usually somewhere in the middle...): 1m13.3s ERROR: FAIL: silently overwrites files via directory symlinks: /usr/share/doc/cups-client/NEWS.Debian.gz (cups-client) != /usr/share/doc/libcups2/NEWS.Debian.gz (?) /usr/share/doc/cups-client/changelog.Debian.gz (cups-client) != /usr/share/doc/libcups2/changelog.Debian.gz (libcups2:amd64) /usr/share/doc/cups-client/changelog.gz (cups-client) != /usr/share/doc/libcups2/changelog.gz (libcups2:amd64) /usr/share/doc/cups-client/copyright (cups-client) != /usr/share/doc/libcups2/copyright (libcups2:amd64) cheers, Andreas cups_1.6.2-10.log.gz Description: GNU Zip compressed data
Processed: cups-client: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Processing control commands: > affects -1 + cups Bug #716867 [cups-client] cups-client: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE Added indication that 716867 affects cups -- 716867: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716867 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b.13737415919010.transcr...@bugs.debian.org
Bug#716843: cups: CUPS doesn't properly initialize Lexmark E238
Package: cups Version: 1.5.3-5 Severity: normal Dear Maintainer, After upgrading my print server to Wheezy, I've had a lot of problems printing on my Lexmark E238 laser printer. When printing from a linux client, it will sometimes print just the top corner zoomed to fill the whole page. This happens roughly half of the time, and only on the first page of a multi page print job. Otherwise it prints properly. I'm using the pcl5 driver. (Generic PCL 5 Printer Foomatic/ljet3). If I print from a Windows box using direct/raw access (with the Lexmark driver specifically for this printer), I get page after page of gobbledegook (probably PCL6 source code.) If I set a windows machine to print using a generic postscript driver, it acts the same as a linux client. It sometimes works, but sometimes prints the first page zoomed way in. Given the symptoms, it seems to me that the printer isn't being properly initialized. It doesn't recognise PCL6, and sometimes gets the resolution wrong using PCL 5. Does anyone have any ideas? I'd really like to have reliable printing again before Jessie comes out. Mark -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 3.2.0-4-kirkwood Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cups depends on: ii adduser3.113+nmu3 ii bc 1.06.95-2 ii cups-client1.5.3-5 ii cups-common1.5.3-5 ii cups-filters 1.0.18-2.1 ii cups-ppdc 1.5.3-5 ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.10 ii ghostscript9.05~dfsg-6.3 ii libavahi-client3 0.6.31-2 ii libavahi-common3 0.6.31-2 ii libc-bin 2.13-38 ii libc6 2.13-38 ii libcups2 1.5.3-5 ii libcupscgi11.5.3-5 ii libcupsimage2 1.5.3-5 ii libcupsmime1 1.5.3-5 ii libcupsppdc1 1.5.3-5 ii libdbus-1-31.6.8-1+deb7u1 ii libgcc11:4.7.2-5 ii libgnutls262.12.20-7 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u1 ii libkrb5-3 1.10.1+dfsg-5+deb7u1 pn libldap-2.4-2 ii libpam0g 1.1.3-7.1 ii libpaper1 1.1.24+nmu2 ii libslp11.2.1-9 ii libstdc++6 4.7.2-5 ii libusb-1.0-0 2:1.0.11-1 ii lsb-base 4.1+Debian8+deb7u1 ii poppler-utils 0.18.4-6 ii procps 1:3.3.3-3 ii ssl-cert 1.0.32 Versions of packages cups recommends: ii avahi-daemon 0.6.31-2 ii colord 0.1.21-1 ii foomatic-filters 4.0.17-1 ii ghostscript-cups 9.05~dfsg-6.3 ii printer-driver-gutenprint 5.2.9-1 Versions of packages cups suggests: ii cups-bsd 1.5.3-5 pn cups-pdf ii foomatic-db20120523-1 ii hplip 3.12.6-3.1 ii printer-driver-hpcups 3.12.6-3.1 ii smbclient 2:3.6.6-6 ii udev 175-7.2 -- debconf information: cupsys/raw-print: true cupsys/backend: ipp, ipp14, lpd, socket, usb, snmp, dnssd -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130713143800.28874.68018.reportbug@qbranch
Bug#716842: cups-filters: please compile with support for using acroread as pdftops-renderer
Package: cups-filters Version: 1.0.34-3 Severity: wishlist Dear Maintainer, Version 1.0.24 of cups-filters introduced the ability to use acroread instead of ghostscript (or poppler) for converting PDF to PostScript in the pdftops filter. Adobe Reader converts to PostScript much much faster than GhostScript which is slow to the point of being unusable on documents with complex transparency. However, the path to acroread (and indeed the other renderers) is set at build time and cannot be changed at run time. If acroread is found in the path at build time, this is used, otherwise it's set to a zero length string and the filter fails when specifying this option (which can be done at run time). I realise, that Debian does not include acroread, but it can be installed from the deb-multimedia package which puts acroread in /usr/bin/. Would you consider configuring cups-filters with the --with-acroread-path=/usr/bin/acroread option? I realise that this is a hack, but at least acroread could be used this way. Thanks, David -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.9-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cups-filters depends on: ii bc 1.06.95-8 ii fonts-freefont-ttf 20120503-1 ii fonts-liberation1.07.2-6 ii ghostscript 9.05~dfsg-8 ii libc6 2.17-7 ii libcups21.6.2-10 ii libcupsfilters1 1.0.34-3 ii libcupsimage2 1.6.2-10 ii libfontconfig1 2.10.2-2 ii libfontembed1 1.0.34-3 ii libgcc1 1:4.8.1-2 ii libijs-0.35 0.35-8 ii liblcms2-2 2.2+git20110628-2.2 ii libpoppler190.18.4-6 ii libqpdf10 4.1.0-2 ii libstdc++6 4.8.1-2 ii ttf-dejavu 2.33+svn2514-3 Versions of packages cups-filters recommends: ii colord1.0.1-1 ii foomatic-filters 4.0.17-1 ii ghostscript-cups 9.05~dfsg-8 Versions of packages cups-filters suggests: ii foomatic-db-compressed-ppds [foomatic-db] 20130609-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130713133534.23708.61009.report...@swires.marshwiggle.net
Processed: Re: Bug#715800: cups: ipp backend gets stuck in "DEBUG: Validate-Job" loop
Processing commands for cont...@bugs.debian.org: > tags 715800 moreinfo Bug #715800 [cups] cups: ipp backend gets stuck in "DEBUG: Validate-Job" loop Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 715800: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715800 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13737200228099.transcr...@bugs.debian.org
Bug#715800: cups: ipp backend gets stuck in "DEBUG: Validate-Job" loop
tags 715800 moreinfo thanks > It is possible that > >* > debian/patches/ipp-backend-abort-the-outer-loop-if-we-get-a-failure-from-send-document.patch, > > debian/patches/ipp-backend-could-get-stuck-in-an-endless-loop-on-certain-network-errors.patch: >Prevent IPP backend from falling into an infinite loop in certain >situations (CUPS STR #4194). > > in unstable's cups is a fix. Testing on an unstable install would be a > way of finding out. However, it may be sufficient to use the ipp backend > from 1.6.2-10. (If this is not a valid procedure, I hope someone will > say so). Hello Daniel, Have you had a opportunity to test with 1.6.2-10 yet? Cheers, Brian. -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/13072013133444.b1f96373e...@desktop.copernicus.demon.co.uk
Bug#716830: Wrong colors are printed on arm device using hpcups
Package: printer-driver-hpcups Version: 3.13.4-1+b1 On a custom built NAS using the armv5tel architecture i have setup cups as a print server. The printer details/configuration are: Description:HP Photosmart 3200 series Driver: HP Photosmart 3200 Series, hpcups 3.13.4 (color, 2-sided printing) Connection: dnssd://Photosmart%203200%20series%20%5B42F8E4%5D._pdl-datastream._tcp.local/ Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided When a test page is printed from the cups administration page, all the details are there, but the colors on tux and the color-wheel are clearly wrong. Everything has a green tint. Perhaps there is an endian-ness problem in the printer driver? I am using a custom kernel and debian-sid: Linux lacie-nas 2.6.38-rc4-09713-ga6682f0-svn-dirty #13 PREEMPT Thu Feb 24 01:37:33 CET 2011 armv5tel GNU/Linux
