I am Till Kamppeter, leader of the OpenPrinting project and also of
cups-filters which is part of OpenPrinting.
The upstream bug tracker is the Linux Foundation one, bugs and feature
requests in cups-filters are filed under the product OpenPrinting and
the component cups-filters.
Here I
The fix prevents the repeated loading of this printer as it considers
the loading done after the first load.
Till
On 06/07/2017 03:05 PM, Samuel Wolf wrote:
Wed Jun 7 20:03:07 2017 Unable to create/modify CUPS queue (Success)!
Here a successful operation was considered an error and this leads to
the repetition.
I have fixed this already in the 1.13.4 release of cups-filters.
Till
On 05/16/2017 02:48 PM, Didier 'OdyX' Raboud wrote:
… but I think it would work with a chmod 744.
Alexander: do you have a serial printer; and could you test?
Till: as you're the initial committer of that code; any opinion ?
The "serial" backend is a CUPS backend which has to run as root to
Thank you for the log file.
The high load was probably caused by cups-browsed repeatedly creating
local queues for the discovered remote queues as it did not recognize
that the queues were already successfully generated.
I have corrected the error checking now to interpret the resulting IPP
Please attach your /etc/cups/cups-browsed.conf and the output of the command
lpstat -v
Also activate debug logging by adding the line
DebugLogging file
to /etc/cups/cups-browsed.conf and restart cups-browsed via
sudo systemctl stop cups-browsed
sudo systemctl start cups-browsed
When
Fixed in cups-filters upstream, BZR rev. 7599.
Thank you for the bug report.
"lpadmin -m everywhere" uses the PPD generator in the CUPS library. The
generator has no public API and so it cannot be used by other programs
using the CUPS library.
Therefore I have copied the PPD generator from
This looks like some bug-in-the-PostScript-interpreter-of-the-printer
issue. Please follow the instructions of the section
PostScript (PDF) printer chokes on the PostScript (PDF) coming from Ubuntu
on
https://wiki.ubuntu.com/DebuggingPrintingProblems
Note that the printing parts of Debian
Fixed in upstream BZR rev. 7592.
Thank you for the bug report.
Fixed in upstream BZR rev. 7588.
Problem were bugs in the calculation of the page geometry in imagetoraster.
Thank you very much for the bug report.
Thank you for testing.
I tried "make install" as root and "driverless" and the symlinks all get
root.root ownerships.
So we can consider this bug as fixed upstream now.
Till
And "lpinfo -v" still does not list it at all?
Please put CUPS into debug mode via:
cupsctl --debug-logging
Then run
time lpinfo -v
and post the output here.
Attach also /var/log/cups/error_log.
Does
lpinfo -m | grep driverless
give some output? Can you post that, too?
Till
Did you install the newly compiled driverless utility correctly into
your system?
Do
ls -l /usr/bin/driverless
ls -l /usr/lib/cups/driver/driverless
ls -l /usr/lib/cups/backend/driverless
Are all the three files the same or are there symlinks pointing to one
of the three files, so that
Added "-T 3" to the ippfind command line in the driverless utility. This
should improve the reliability in finding IPP printers.
I have committed this as rev. 7585 to the cups-filters upstream BZR
repository. Please test.
Till
Strange, seems that avahi-daemon does not hold the info about the
printer in a local cache. And when the network is more busy, the
response times to requests to avahi-daemon get longer.
How does it behave with
ippfind -T 2
ippfind -T 3
?
Till
The servers of the Linux Foundation are back online and so I have
committed rev. 7583 and also released cups-filters 1.13.1.
Till
The problem with cups-browsed erroring out when
CreateRemoteCUPSPrinterQueues=No is set and queues from the previous
cups-browsed session did not get removed I have solved now.
The fix is intended to be BZR rev. 7583, but the servers of the Linux
Foundation went completely down, so I attach
Problem of generated queues not being removed solved on upstream BZR,
rev. 7582.
Till
If you have observed the problem with the current BZR state of
cups-filters. Please try
sudo systemctl stop cups-browsed
check whether all cups-browsed-generated queues have gone away and run
sudo systemctl start cups-browsed
Is the setting now obeyed?
Did all the generated queues go away
On 12/17/2016 09:52 AM, Brian Potkin wrote:
[...]
./configure
This file did not exist, so I ran autogen.sh to get it. Was that ok?
Yes, this was correct. I forgot to put ./autogen.sh here.
[...]
And now everything looks fine. The IPP printer remains visible after
doing 'logrotate -vf
I have also fixed #848167 with the commit yesterday, so in the current
BZR state the problem of the queues not being removed is fixed.
Does the problem you mention in this bug occur with the current BZR
state (rev. 7580)?
Till
Fixed in the upstream BZR repository of cups-filters (rev. 7580).
Till
tkin wrote:
On Fri 16 Dec 2016 at 21:02:34 -0200, Till Kamppeter wrote:
I have fixed the problem (at least I hope so) in the upstream BZR repository
of cups-filters (rev 7580, only file util/cups-browsed.c needed a change).
If possible, please test.
I will do so. Probably tomorrow morning
I have fixed the problem (at least I hope so) in the upstream BZR
repository of cups-filters (rev 7580, only file util/cups-browsed.c
needed a change).
If possible, please test.
If you are not familiar with working with source code, please tell me
and I will do the 1.13.1 release so that
On 12/15/2016 11:48 AM, Brian Potkin wrote:
On Thu 15 Dec 2016 at 10:35:00 +, Brian Potkin wrote:
The same behaviour can be reproduced with the commands:
logrotate -f /etc/logrotate.d/cups-daemon
or
systemctl restart cups cups-browsed.service
or
systemctl restart cups ; sleep 3 ;
I saw that Mike has done the still missing fix now. I have tried it out
and it works now. So it is fixed in the current GIT state of CUPS. To
fix the package in experimental, you need to replace the file
filter/raster.c by the current one from GIT.
Till
I observed this already by myself on the HP DeskJet 2540 and reported it
to CUPS upstream as
https://github.com/apple/cups/issues/4934
It is partially fixed, but still needs more work from the CUPS side.
Till
On 12/13/2016 05:51 AM, Didier 'OdyX' Raboud wrote:
I'm unconvinced that it makes sense for cups-filters to pull cups-ipp-utils:
This package provides IPP utilities for developers and system administrators
in all installations that have CUPS (aka, _all_ desktops). Is it not possible
to
On 12/11/2016 05:18 PM, Brian Potkin wrote:
Package: cups-filters-core-drivers
Version: 1.13.0-2
Severity: normal
The driverless utility/backend requires ippfind to be useful. Shouldn't
cups-ipp-utils be a dependency of cups-filters-core-drivers?
So please add cups-ipp-utils to the
Didier, note that rastertopdf was installed all the time, via the
cups-filters-core-drivers binary package. It serves for PWG Raster input
(so that the combo of CUPS and cups-filters emulates an IPP Everywhere
printer). Now with the new CUPS this rastertopdf understands Apple
Raster in
On 12/08/2016 05:54 PM, Brian Potkin wrote:
The printing system is intended to put ink or toner on paper. If it does
not do that it has failed. Can we agree on that?
Does it matter for the primary purpose of printing whether a PDF produced
during the process is searchable or not?
Note that
Another possible issue:
The mimefx.convs rule
application/pdf application/vnd.cups-pdfprintfx 0 pdftopdffx
makes the pdftopdf filter not being used, leading to many CUPS options,
like number-up, page-ranges, ... not working any more.
Is this intended, for example because the output of
On 10/18/2016 02:51 PM, Roger Shimizu wrote:
Dear Printing team,
I'm almost finished packaging “fxlinuxprint”.
Because I think it's more proper to ask for sponsorship here, than the
mentors list, I'm wondering whether anyone can sponsor this upload.
Thanks for working on this printer driver.
Thank you very much for the patch. I have applied it to the upstream BZR
repository now (rev. 7541).
Note that I had to do a little fix on the patch. The original one
applied both the BrowseInterval and BrowseTimeout directives to the
BrowseInterval variable. I have also added some info to
Sorry for not having seen this mail in the first place.
There are two parameters: BrowseInterval (currently 60 sec) and
BrowseTimeout (currently 300 sec). Both were configurable in CUPS (<
1.6) and are hardcoded in cups-browsed. It is a good idea to make them
configurable and it should be
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)
Should be fixed in cups-filters 1.11.3 (in Debian GIT repo but package
not released yet).
Make also sure you have cups 2.2.0-2 installed.
On 09/17/2016 11:08 AM, Jonas Smedegaard wrote:
Did you test that the multi-arch packages work in a multi-arch
environment? Looking at the symbols file, it seems headers do vary.
- Jonas
I have simply re-introduced the accidentally dropped multi-arch support
which Doko has introduced in
When re-applying the multi-arch support I based myself on the original
implementation in Ubuntu:
http://launchpadlibrarian.net/235445264/ghostscript_9.16~dfsg~0-0ubuntu3_9.16~dfsg~0-0ubuntu4.diff.gz
Till
~dfsg+1/debian/changelog2016-09-16 18:12:46.0
-0300
@@ -1,3 +1,9 @@
+ghostscript (9.19~dfsg+1-0ubuntu4) yakkety; urgency=medium
+
+ * Multiarchify the library packages.
+
+ -- Till Kamppeter <till.kamppe...@gmail.com> Fri, 16 Sep 2016 18:12:58 -0300
+
ghostscript (9.19~
On 09/03/2016 07:42 PM, Brian Potkin wrote:
# DomainSocket /var/run/cups/cups.sock
Thank you. As this line is commented out cups-browsed connects by the
socket out-of-the-box on your machine.
Till
Brian, thank you very much for the testing. I will do the next (bug fix)
release containing also other fixes (version 1.11.3) most probably on
Monday.
One question: Did cups-browsed use the socket out-of-the-box or did you
need to set it in cups-browsed.conf?
Till
The problem is most probably caused by inconsistency in how cups-browsed
accesses the local CUPS daemon, for some accesses it uses the domain
socket (which made it mostly well working in your case) and at other
places, especially also during shutdown, it accesses localhost:631 (this
is why it
I have done the following changes now:
In the upstream BZR repo of cups-filters I have removed the now unneeded
"Wants=cups.service" from cups-browsed.service (BZR rev. 7474).
In the Debian GIT repository I have added a "Depends: cups-daemon" to
the cups-browsed binary package, as
I have added a new quirk rule to pdftops now that in hybrid mode also
for Dell PostScript printers Poppler will get used.
Note also that pdftops uses the hybrid mode by default.
Till
Thank you for your contribution.
I have added the documentation for the pdfAutorotate option to the
README file in the upstream repository now, BZR rev. 7461.
Till
Fixed in cups-filters upstream, BZR rev. 7455.
Thank you very much for the bug report.
The wrong documentation of the input formats of sys5ippprinter was also
in the man page of cups-browsed.conf (utils/cups-browsed.conf.5) and in
README. I have fixed it there, too.
The fix will appear in
On 03/31/2016 02:29 AM, Jason Lewis wrote:
* What led up to the situation?
trying to compile and install the Perl module Net::CUPS::Destination
Your actual problem is that you are not able to build or install this
Perl module. It is not due to the fact you mention below. To find
foomatic-filters I have discontinued upstream, as it seems that the only
printing environment used in Linux nowadays is CUPS.
Loosing beh in the upstream world by that I decided to re-introduce it
in cups-filters (where foomatic-rip also has its upstream home now). In
cups-filters I have
I have done an alternative (and hopefully better) fix for this problem
by re-implementing beh in C and adding it to cups-filters upstream (from
version 1.6.0 on).
Till
I think this is a good idea. It makes one of the two utility packages be
installed if at least one is available (ex: Ubuntu with only Main) and
does not error if none is available. And it prefers the better if both
are available (Debian and Ubuntu with Main and Universe).
Let us go this way.
Thanks for the bug report.
Fixed in cups-filters upstream, BZR rev. 7446, to be released with
cups-filters 1.8.2.
Now there is a new configuration option:
CreateRemoteRawPrinterQueues Yes
to be set in cups-browsed.conf. Then cups-browsed also takes into
account remote raw queues. See also
Package: ghostscript
Version: 9.16~dfsg-2.1
Matthias Klose from Ubuntu has added multi-arch extensions for the libgs
of Ghostscript. The patch from Ubuntu is here:
http://launchpadlibrarian.net/235445264/ghostscript_9.16~dfsg~0-0ubuntu3_9.16~dfsg~0-0ubuntu4.diff.gz
Can this be added to the
On 12/15/2015 03:07 PM, Till Kamppeter wrote:
Splitting done in Debian GIT repository of cups-filters, ready for
release of 1.4.1-2.
Sorry, 1.4.0-2.
Till
Splitting done in Debian GIT repository of cups-filters, ready for
release of 1.4.1-2.
Till
Hi,
I have added the Braille support and today discussed it with the Ubuntu
folks, and there we came to the conclusion to move Braille into a
separate binary package named cups-filters-braille. I was about to do
this now.
Especially in Ubuntu the new dependencies would need a move of
On 12/14/2015 01:30 PM, Didier 'OdyX' Raboud wrote:
I'm likely to wait for 1.4.0 upstream release for an upload to unstable,
and will then prepare the package for jessie (if the Security Team
agrees).
I have 1.4.0 released upstream now, including the fix. I have also
updated the Debian
On 09/27/2015 10:13 AM, Didier 'OdyX' Raboud wrote:
Indeed, it seems that you can't. I can confirm that cups and
foomatic-filters are not coinstallable, at least since jessie.
The most important part of foomatic-filters, foomatic-rip, is included
in cups-filters, only thing not included is
This is fixed now in cups 2.1.0-3.
It is the following upstream bug report:
https://www.cups.org/str.php?L4707
The fix I have backported to said cups release.
Till
On 09/14/2015 02:03 PM, Fabian Greffrath wrote:
Am Montag, den 14.09.2015, 13:49 -0300 schrieb Till Kamppeter:
The fix I have backported to said cups release.
Fine, but why have you set yourself as Author for the patch?
- Fabian
Corrected in Debian GIT repo. Sorry.
Till
On 09/14/2015 02:03 PM, Fabian Greffrath wrote:
Am Montag, den 14.09.2015, 13:49 -0300 schrieb Till Kamppeter:
The fix I have backported to said cups release.
Fine, but why have you set yourself as Author for the patch?
- Fabian
Sorry, cut-and-paste error, I have copied the header
On 08/12/2015 03:12 PM, Didier 'OdyX' Raboud wrote:
That said, I'm not going to take such an extensive patch on my
maintainer shoulders, and this patch should really live on the upstream
side. Till: would you be open to merge this upstream? [1]
OdyX
Raphael, thank you very much for the patch.
On 02/22/2015 01:25 AM, tony mancill wrote:
Package: hplip
Version: 3.14.6-1
Severity: wishlist
Dear Maintainer,
Please consider packaging the latest upstream version. The attached
patch will build a working package for 3.15.2.
Thank you!
tony
Thank you for the patch. As I have
I think we do not really need this patch. What is does is allowing to
set color calibration mode as default setting for a print queue via the
CUPS web interface. But this option should only be set when calibrating
the printer, not permanently, so Mike Sweet is right that this is a
per-job option.
On 11/01/2014 09:17 PM, ael wrote:
On Fri, Oct 31, 2014 at 11:35:05PM +0100, Till Kamppeter wrote:
USB printer does not print or prints garbage
on
https://wiki.ubuntu.com/DebuggingPrintingProblems
Somehow my last message repeated -o usb-no-reattach-default=true
when the first should have
I by myself have never tested cups-browsed with that many printers or
otherwise very noisy networks. It is also the first time that someone
reports that cups-browsed takes a lot of CPU.
cups-browsed is running an event loop and if an event (= broadcast
signal from local avahi-daemon or from
Your problem seems to be a bad interference between your printer and the
USB CUPS backend. Please follow the instructions of the section
USB printer does not print or prints garbage
on
https://wiki.ubuntu.com/DebuggingPrintingProblems
Till
--
To UNSUBSCRIBE, email to
On 10/30/2014 08:29 AM, Didier 'OdyX' Raboud wrote:
Hi Michal, and thanks for your bugreport,
I think I understand the problem you're having, let's see.
Le mercredi, 22 octobre 2014, 13.12:51 Michal Hocko a écrit :
(..)
Of course I had
BrowseAllow all
present and that caused all remote
On 10/30/2014 01:13 PM, Tim Waugh wrote:
I've added support for 'BrowseAllow All' in revno 7303.
Tim, thank you very much for the quick help.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
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.
This got also reported to Ubuntu as
https://bugs.launchpad.net/debian/+source/system-config-printer/+bug/1156398
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 09/30/2014 07:34 PM, Didier Raboud wrote:
Till: would you have an idea of what is causing #763517 ?
Unfortunately, I have no idea about what is exactly happening here. I
have forwarded this to Joe Simon who created the color management
extension patch. Let's wait for his answer.
Till
I have fixed this regression on the BZR repository, rev. 7241. Thank you
for the bug report.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
It seems that cupsd needs to check whether there is a running web
interface session and consider itself non-idle then.
colord will probably also need some tweaking for laptop/mobile battery
saving environments.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with
I have fixed this now upstream in BZR revision 7203. The fix will be
part of the 1.0.54 release.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
socket activated (similar to -l flag for launchd).
- Initialize addrlen to sizeof(addr) to make getsockname() work.
- Correct environment variable name used to check event type
- Get UPSTART_FDS simply with atoi()
- Perform explicit return code checking from getsockname function call
Author: Till
Cameron, first, thank you for your patch.
Here my remarks:
1. I have modified the CUPS daemon to have working avahi-daemon support
even if avahi-daemon is started after cupsd or if avahi-daemon is
restarted while cupsd stays running. cupsd simply stops broadcasting
when avahi-daemon disappears
Thank you very much for your bug report and your patch.
I fixed the bug in the hplip package for Debian and Ubuntu now (SVN
repository, rev. 629).
This should also get fixed upstream. Please report this bug with your
patch upstream at http://launchpad.net/hplip/. Thanks in advance.
Till
--
On 03/27/2014 07:16 PM, Jean Tourrilhes wrote:
Already done :
https://bugs.launchpad.net/hplip/+bug/1298194
Great, thanks. This is totally OK.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
The DSC warnings are caused by a bug in Ghostscript (needs upstream
report on http://bugs.ghostscript.com/), sometimes Ghostscript inserts
%BeginResource (only one % character) instead of %%BeginResource.
This problem is still present in Ghostscript 9.10.
One can easily show it running only
Reported bug to Ghostscript upstream:
http://bugs.ghostscript.com/show_bug.cgi?id=695082
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Sanjay. can you please go to
http://bugs.ghostscript.com/show_bug.cgi?id=695082
and answer the questions of the Ghostscript developers so that they can
find and fix the bug? Thanks.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
I have fixed the problem upstream (BZR rev. 7159) now. I do not use
PATH+MAX any more for strings which are used to hold a command line.
Command lines have 65535 bytes now.
Please test and tell whether it solves the problem. If so, I will
release a new cups-filters version.
Till
--
To
On 05.02.2014 17:12, Didier 'OdyX' Raboud wrote:
Control: tags -1 +moreinfo
Hi Till,
Can you provide more explanations about this file (introduced in
1.0.19)?
Le lundi, 27 février 2012, 16.12:10 Samuel Bronson a écrit :
(…)
File: /etc/fonts/conf.d/99pdftoopvp.conf
(…)
I think the file listed
For actual printing commandtops is not needed, but it seems that CUPS
hardwires the requirement of its presence to unlock printing to a
PostScript printer (PPD without *cupsFilter: line).
We either need to patch CUPS to remove this hard requirement (but still
allow the use of commandtops if it is
Should be fixed in cups-filters 1.0.40 and later:
[...]
CHANGES IN V1.0.40
- pdftops: Introduced new hybrid renderer: Here usually
Ghostscript is used, but if the printer is a Brother,
Minolta, or Konica Minolta Poppler's pdftops gets used. This
is a quirk
On 01/23/2014 01:22 AM, Ryo Furue wrote:
It is
http://bugs.ghostscript.com/show_bug.cgi?id=694968
This is fixed upstream now.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Please report this upstream to Ghostscript's bug tracking system
http://bugs.ghostscript.com/
Preferably attach a patch to the bug report.
Thanks.
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Originally, the simple paper size names A4, Letter, ... referred to
paper sizes with smaller margins/a larger printable area, but these
sizes do not allow Duplex printing, jobs simply came out one-sided.
Office applications only used the simple names for paper sizes as part
of the document (not of
Please follow the instructions of the section USB printer does not
print or prints garbage on
https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
For lpadmin commands it depends where -E is specified. -E before -p
enforces encryption, but -E after -p directly enables the queue.
So you have to take care that the command line arguments of lpadmin are
in the right order in the maintainer scripts.
We do not want to enforce encryption as it is
On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote:
Control: tags -1 +moreinfo
Hi Lionel and Wolfgang,
hi Till,
thanks for your detailed bugreports and proposed patch.
Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit :
Let FOO be a printer configured in CUPS with an
On 01/05/2014 01:23 PM, Didier 'OdyX' Raboud wrote:
Hi Till,
Le dimanche, 5 janvier 2014, 13.12:31 Till Kamppeter a écrit :
On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote:
Your proposed patch is functionally equivalent to disabling the
get-ppd- file-for-statically-configured-ipp-shared
On 01/05/2014 01:36 PM, Wolfgang Walter wrote:
On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote:
On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote:
Control: tags -1 +moreinfo
Hi Lionel and Wolfgang,
hi Till,
thanks for your detailed bugreports and proposed patch.
Le samedi, 16
I have already packaged GS 9.10 for Ubuntu, so it only needs to get
back-synced 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
On 07/24/2013 08:10 PM, Jim Paris wrote:
Maybe the cups-browsed leak is related to:
https://bugzilla.redhat.com/show_bug.cgi?id=959682
I can't figure out how to see what their fix was, though.
-jim
See also the upstream bug
https://bugs.linuxfoundation.org/show_bug.cgi?id=1116
and
I have fixed this in cups-filters upstream now. If a renderer
(Ghostscript, Poppler, Adobe Reader) is not installed, its executable
path(s) are set to the executable name. With execv() replaced by
execvp() in pdftops.c, the renderer will also work when only installed
at run time, also when the
Could perhaps a no-change rebuild of cups-filters help?
Till
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 06/29/2013 05:56 PM, Brian Potkin wrote:
... or forward upstream, if they are of use.
I am the upstream maintainer of cups-filters and I am also reading the
printing-related Debian bug reports.
Thank you very much for contributing the man pages.
I have now added them to the upstream BZR
I have now changed the cost factors of the filters which come with the
cups-filters package (in the upstream BZR repository, will be part of
cups-filters 1.0.35).
Now the cost factor of pstops in CUPS can stay 66, so the upstream
default does not need to be changed and with the new cost factors
101 - 200 of 322 matches
Mail list logo
