gpr is not only not upstream-maintained any more and depending oon the
obsolete GTK2, it is also only used for printing with LPD/gnulpr/LPRng,
all these being printing systems which are obsolete for near 2 decades
(replaced by CUPS) and all not maintained upstream any more.
So it does not
I have done several fixes on cups-filters upstream now, please try a current GIT
snapshot of cups-filters.
Till
On 22/09/2019 13:25, Brian Potkin wrote:
Would this do?
cat /usr/share/cups/data/form_russian.pdf | gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH
-dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout
-sDEVICE=cups -r600x600 -dDEVICEWIDTHPOINTS=595
This I have already fixed upstream. It was already reported as upstream
issue #79 and Debian bug #916149.
Till
Anthony, thanks for testing. The fix is on its way into Debian and Ubuntu.
Till
cups-browsed is part of cups-filters, not of CUPS. The patch you find here:
https://github.com/OpenPrinting/cups-filters/commit/0d29084a864ca80ada8b4eafc2d36f072e06f984
Till
Anyone suffering this problem, can you apply my upstream fix and check
again whether this solves the problem? Thanks.
Till
I have (hopefully) fixed this bug upstream now (commit 0d29084a864c).
In case of a shutdown of cups-browsed the queues were even removed with
jobs. This I have corrected now, now cups-browsed really only removes
print queues when they do not have jobs.
The problem occurred independent of
Usually cups-browsed does not remove a print queue if it still has jobs.
If it is stopped and one of its queues still has jobs, this queue is
left intact. Next time it starts it connects the this remaining queue
with its printer if it re-discovers the printer, or removes it if the
printer has
I have fixed this bug and two others one in the HPLIP package for Ubuntu
Cosmic (18.10). Simply overtake the two patches which I have added.
https://launchpad.net/ubuntu/+source/hplip/+changelog
https://launchpad.net/ubuntu/+source/hplip/3.18.7+dfsg1-2ubuntu2
An update:
On Ubuntu the timeouts in the CUPS autopkgtest do not happen any more
with Ghostscript 9.25 which got released yesterday and is highly
recommended by upstream to fix the regressions in 9.24.
Till
I have updated Ubuntu's Ghostscript from 9.23 to 9.24 as upstream
recommended it highly for security reasons.
The autopkgtests all passed without problems for Ghostscript 9.23 on
Ubuntu. On 9.24 I get a timeout on drv:///sample.drv/generic.ppd:
--
* Driver
On 31/08/18 15:36, Didier 'OdyX' Raboud wrote:
Le vendredi, 31 août 2018, 01.25:24 h CEST Jonas Smedegaard a écrit :
Do the freshly released experimental Ghostscript release help anything?
It doesn't seem to, unfortunately. :-(
To reproduce the issue; just run this as root:
Wenbin Lv, thank you very much for testing.
I have released version 1.21.1 with the fix. It will soon appear in Debian.
Till
(20170121-1ubuntu1) bionic; urgency=medium
+
+ * In the autopkgtest replaced the call of pstotext by ps2txt
+as pstotext upstream is unmaintained for years and stopped
+working with Ghostscript whereas ps2txt is part of ghostscript
+(LP: #1762778).
+
+ -- Till Kamppeter <till.kamppe
Which CUPS version are you using on the system where the build failure
happens?
The problem seems to be the same as I have already observed with HPLIP.
Since CUPS 2.2.0 at some points
#include
lines need to be added.
Unfortunately, I cannot reproduce your problem on Ubuntu Yakkety (16.10)
I have forwarded this report to Tim Waugh from Red Hat, original author
of system-config-printer and he has answered me the following:
--
can you check this ppdcache.py problem mentioned here?
I've committed a change which should stop the looping by failing the
call on IOError.
Could perhaps a no-change rebuild of cups-filters help?
Till
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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
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
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
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
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
On 03/27/2012 09:28 PM, Helge Kreutzmann wrote:
Thanks again for your help. I rebuild cups-filters 1.0.7-1 in testing
(and the required dependencies from sid, where necessary) and now
printing on the queue you asked me to set up (with the PPD file from
you) works again as expected.
Great,
The problem should be fixed by the recent fixes in cups-filters, version
1.0.5 or later.
Till
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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
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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
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
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
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
@@
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
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
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
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
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
--
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
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
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,
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
41 matches
Mail list logo
