On 31/03/2024 22:23, Paul Szabo wrote:
(Sadly, my other issues were "declined" upstream. Maybe they know what
they are doing...)
Where did you report them?
Till
On 30/03/2024 23:19, Paul Szabo wrote:
Most issues now reported upstream:
https://github.com/OpenPrinting/cups/issues/917
https://github.com/OpenPrinting/cups/issues/918
https://github.com/OpenPrinting/cups/issues/919
The issue with pdftopdf not reported upstream, because I could not find
the
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
Probably you are hitting this bug
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1971242
The bug is fixed upstream in CUPS 2.4.3 and later and I have created 2
Stable Release Updates (SRUs) for Ubuntu Jammy (CUPS 2.4.1) and Lunar
(CUPS 2.4.2). So you could try these fixes and they could
On 27/06/2022 19:26, Gareth Evans wrote:
"testq" already exists, so I changed the queue name to avoid any potential
caching effects etc in case that were possible.
$ sudo lpadmin -p testqq -v ipp://192.168.0.14/ipp/print -E -m
driverless:ipp://192.168.0.14/ipp/print
lpadmin: Printer drivers
And are you able to print now?
Till
On 27/06/2022 17:57, Gareth Evans wrote:
However that is when the laptop is connected to 5GHz wifi.
If I change to the 2.5GHz connection (same router) on which (router and
frequency) the printer is connected:
$ avahi-browse -rt _ipp._tcp
+ wlp1s0 IPv4
Now run the command
driverless
and, if you get the URI, run
lpadmin -p envy -E -v ipp://localhost:6/ipp/print -m everywhere
Does it work now?
Till
On 06/04/2022 11:28, alain wrote:
Package: cups
Version: 2.4.1op1-2
Followup-For: Bug #1008997
X-Debbugs-Cc:
First step is to go to
http://www.openprinting.org/
There you scroll down and find a link to the "Driverless Printers" list.
Click "Browse". You get onto
https://openprinting.github.io/printers/
into the search field enter "Envy 553". The last digit does not matter.
Different last digits
The log message "Unable to do two-sided printing" comes from the "ipp"
CUPS backend, part of CUPS. It seems that the backend does not find the
"sides" attribute in the printer's IPP attributes.
See the code here:
--
if (ipp_status == IPP_STATUS_OK_IGNORED_OR_SUBSTITUTED ||
Probably cause by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006853
Till
he DSC comments, letting the second number in the "%%Page:"
lines going from 1 to 993 instead of being the same as the first number,
starting from 1 again and again. This seems to make the viewers
accepting all pages.
I hope this gives some insight.
On 01/10/2021 13:11, Andre Heider
Andre, could you attach your PostScript file, once the original and also
the one you get after pre-processing when using "GSCall echo %s %s %s;
cp %s /tmp"? Thanks.
--
On 28/09/2021 14:20, Andre Heider wrote:
Indeed, still only getting an empty pdf on that file too.
That's another
Updating SANE (libsane1, sane-backends) from 1.0.31 to 1.0.32 could
perhaps fix the scanning with installed ipp-usb and the "escl" backend.
1.0.32 (released upstream a few weeks ago) has a lot of fixes and
improvements on the "escl" backend.
You could install sane-airscan. This is an extra
On 23/02/2021 13:17, Brian Potkin wrote:
escl is capable of working with ipp-usb but does not. This seems to
be a bug in SANE's libsane-escl, so I am reassigning your report to
libsane1.
Note that the "escl" backend got improved a lot in sane-backends 1.0.32
which got released recently. I
OK, no I understand, fresh installation or live ISO all works perfectly
as intended, old installation shows the problem, so further
investigations only on the old installation ...
Till
On 15/02/2021 14:27, mh wrote:
I then investigated the LIVE-ISO. To my surprise ipp-usb is installed
within the LIVE-ISO.
ipp-usb is part of the standard installation in Debian and Ubuntu, to
support printers which do driverless IPP printing. Standard-conforming
printers should work
Alexander,
on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982742
Michael Hatzold (CCed) reports a problem with ipp-usb. The printer
provides a 7/1/4 interface on USB, meaning that it supports IPP-over-USB
and with this, according to the standards, driverless printing (and
scanning if
Please report this to CUPS upstream at
https://github.com/OpenPrinting/cups
Note trhat CUPS is not maintained at Apple any more but at OpenPrinting now.
We need the USB IDs (VID/PID) of all affected devices, at least of as
many devices as possible.
Till
On 24/01/2021 23:46, Chris
I have released cups-filters 1.28.7 with the fix now.
https://github.com/OpenPrinting/cups-filters/releases/tag/1.28.7
I have investigated the problem further and the problem is caused by
"driverless" sending get-printer-attributes IPP requests to each printer
it lists, to check the quality of driverless printing support. See
https://github.com/OpenPrinting/cups-filters/pull/235
This makes "driverless" taking
The problem also got reported upstream:
https://github.com/OpenPrinting/cups/issues/65
Could you also see the discussion there and try what got suggested there?
I by myself am not able to reproduce it, so I need someone who can
reproduce it to find out under which conditions it happens.
Great, so I will base my Ubuntu package also on the new version.
OdyX, could you update the Debian packaging appropriately, too? Thanks.
Till
On 04/08/2020 20:10, Alexander Pevzner wrote:
I think I will merge -unstable in few hours and will release result as
0.99.12. It would be nice, if
sane-airscan got uploaded something like 3 weeks ago and is still stuck
in NEW. What is happening? What is missing?
OdyX, as I like to add sane-airscan to Ubuntu 20.10 and it will most
probably not get into unstable in time before Ubuntu's Feature Freeze on
August 27, I would like to ask you
On 17/07/2020 12:54, Brian Potkin wrote:> I am very much attracted by
the idea of a USB connected printer becoming
immediately available when it is plugged in, so a Recommends: ipp-usb
would be ok with me.
Yes, I would very much like this, too, for Ubuntu into which both CUPS
and ipp-usb get
On 07/07/2020 22:25, Didier 'OdyX' Raboud wrote:
For the record, I am primarily concerned about the printing support in Debian,
which packaging I carry mostly alone (I get great help from Brian Potkin for
bug triaging, and Till Kamppeter for upstream and Ubuntu support). I don't
really intend
Package: wnpp
Severity: wishlist
* Package name: sane-airscan
Version : 0.99.8
Upstream Author : Alexander Pevzner
* URL : https://github.com/alexpevzner/sane-airscan
* License : GPL-2+ with sane exception (same as sane-backends)
Programming Lang: C
[ CCed debian-printing and Alexander Pevzner ]
Hi,
I have worked a lot with Alexander Pevzner on making ipp-usb what it is
now and I also have succeeded to get localhost support into Avahi.
Most was already told in the initial report, but I have some additional
remarks:
- IPP-over-USB is
I have done this already for Ubuntu in the 1.34-2ubuntu1 package. "dpkg
-L ippusbxd" gives the following 4 non-documentation files in the package:
/.
/etc
/etc/apparmor.d
/etc/apparmor.d/usr.sbin.ippusbxd
/lib
/lib/systemd
/lib/systemd/system
/lib/systemd/system/ippusbxd@.service
/lib/udev
Recently Avahi 0.8.0 with my localhost support patch included got
released. See
https://github.com/lathiat/avahi/releases/tag/v0.8
See also
https://bugs.launchpad.net/bugs/1864207
Till
ing them inaccessible for the sub system which is actually
responsible for them. Therefore there are also rules for skipping some
devices.
.
This patch adds skipping rules for printers, as they have to belong to the
"lp" group for CUPS or Printer Applications to be able to access th
First, this is definitely a CUPS upstream bug, so please report it on
the CUPS GitHub, also supplying all the information which you have
gathered and attaching the files which I had asked for.
https://github.com/apple/cups/issues/
Probably it can be solved by adding a simple NULL check.
At
We need a way to reproduce the bug and also a backtrace with line
numbers of the source files.
So please attach the PDF input file which leads to the crash. Also
attach your printer's PPD file, from the /etc/cups/ppd/ directory, named
by the name of your print queue.
Please also try to
This is solved in Ubuntu:
https://launchpad.net/ubuntu/+source/hplip/3.19.12+dfsg0-4ubuntu1
You could add the patch for Python 3.8 support to the Debian package.
Till
In a very recent commit I have added crash guards to the
is_local_hostname() function, which cover also the case of host_name
being NULL:
https://github.com/OpenPrinting/cups-filters/commit/4157690bf
I hope this helps here.
But anyway, thanks for the deep analysis of the problem.
Till
I have forgotten to check the build Build-Depends:. The following need
to get added:
autoconf-archive,
libpng,
libcurl4-gnutls-dev,
libxml2-dev
The first is needed to make the package build at all, the others for the
package to build with the newly added backends.
Till
Hi,
I have found the cause of the printers ignoring the paper tray selection.
The problem is that the paper tray names ("Tray-1", "Tray-2", ...) in
the PPD files got wrongly translated to IPP attribute names ("tray--1",
"tray--2", ... note the double-dash) by the CUPS "ipp" backend when
The problem is discussed here:
https://github.com/vitorbaptista/pyppd/issues/2
(Upstream Issue #2 of pyppd)
Till
Package: python-reportlab
Version: 3.5.23-1
Severity: important
The binary package python3-renderpm (source: python-reportlab) depends
on the gsfonts package and this dependency should be replaced by
fonts-urw-base35.
The purpose of the gsfonts package is providing the 35 standard
Package: libwmf
Version: 0.2.8.4-17
Severity: important
The binary package libwmf0.2-7 (source: libwmf) depends on the gsfonts
package and this dependency should be replaced by fonts-urw-base35.
The purpose of the gsfonts package is providing the 35 standard
PostScript fonts to Ghostscript,
On 05/02/2020 20:14, Yves-Alexis Perez wrote:
So, I'm even more confused. I've upgraded again cups-filters (to 1.27.0-2) in
order to do a comparison check, and tried to print, and it did work (with the
Brother PPD, unchanged).
This looks strange, there is no change in the pdftops filter which
I have tried it also and with the command line
cupsfilter -p ../HL5250DN.ppd -i text/plain -m
application/vnd.cups-postscript -e ~/.bashrc > out.ps 2>log
I got valid PostScript output with a PJL header. Note that I had to
specify both input and output MIME types.
Probably in the cases
The warning about not being able to convert color input into grayscale
is principally no problem for you, as monochrome PostScript printers can
receive color input without any problems, they convert the input by
themselves.
What this warning tells to me is that you upgraded from a
I have done several fixes on cups-filters upstream now, please try a current GIT
snapshot of cups-filters.
Till
Unfortunately, HP has also invented some page size entries named
"Custom", being a copy of US Legal, for some of their inkjets in
hpcups.drv. I have fixed this for Ubuntu. See
https://launchpad.net/ubuntu/+source/hplip/3.19.6+dfsg0-1ubuntu1
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
Fixed upstream. Thanks for the bug report.
See https://github.com/OpenPrinting/cups-filters/issues/148
Will be included in the next release, 1.25.5.
Till
This is caused by changes in CUPS 2.2.12. I have already reported an
appropriate issue on CUPS upstream:
https://github.com/apple/cups/issues/5639
Till
A year ago, I have already started packaging ippsample but did not
follow it any further because there were no upstream releases of it yet.
Here is the result of my upload to Ubuntu Universe:
https://launchpad.net/ubuntu/+source/ippsample
Feel free to update it to the current state of the art
I have released cups-filters 1.22.5 upstream now with the fix.
Till
Thanks for reporting this.
I have fixed the problem now by changing the Ghostscript call to count
pages in a PDF file.
See
https://github.com/OpenPrinting/cups-filters/commit/297cc2d
I found this solution with the help of a bug report to Arch Linux:
https://bugs.archlinux.org/task/62251
Does
gs -o - -dNODISPLAY
using Ghostscript 9.27, with being a PDF file which you do
not succeed to print due to this problem, give you a list of "Page XX"
lines for each page in the PDF file (plus some other irrelevant lines)?
Can you post the output of the command here?
Till
On 10/01/2019 09:43, Didier Raboud wrote:
Le 10.01.2019 09:22, Till Kamppeter a écrit :
On 10/01/2019 08:56, Didier 'OdyX' Raboud wrote:
'cups-genppdupdate -x' and restarting cups fixed the problem (-x allows
update across major Gutenprint releases).
Till: it seems that our trigger
On 10/01/2019 08:56, Didier 'OdyX' Raboud wrote:
'cups-genppdupdate -x' and restarting cups fixed the problem (-x allows
update across major Gutenprint releases).
Till: it seems that our trigger is not enough for these. Opinions?
For me it looks like that our trigger needs to run
Bernhard, thank you for your patches. I have applied them (slightly
changed) to cups-browsed upstream. They actually do not do any
functional changes, so if the BrowseFilter facility does not work as
expected, this is another bug and this bug was probably there before.
Till
This I have already fixed upstream. It was already reported as upstream
issue #79 and Debian bug #916149.
Till
On 13/12/2018 19:45, Brian Potkin wrote:
On Mon 22 Oct 2018 at 08:54:52 +0200, Didier 'OdyX' Raboud wrote:
Control: reopen -1
Control: reassign -1 cups-daemon 2.2.8-5
Control: retitle -1 cups-daemon: Please consider making cups-browsed a Suggests
Control: affects -1 +cups-browsed
Le dimanche,
Thanks for the feedback.
Till
Fixed upstream in commit f3d48ecd.
The checking for HTTP timeouts on queue creation has be done at the
wrong place, leading to crashes on queue removal, which happens on shutdown.
Till
On 06/12/2018 21:57, Didier 'OdyX' Raboud wrote:
Control: tags -1 +help
Le mercredi, 5 décembre 2018, 13.57:04 h CET Brian Potkin a écrit :
The file list for printer-driver-hpcups is:
…
But the package description says:
It does not provide PPDs for the fax functionality of HP's multi-
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 the disappearing queue problem upstream in commit dd862c9b.
What happened is that one cannot reliably determine the temporary nature
of a CUPS queue via printer-is-temporary. So I check whether the queue
is shared instead and as any shared queue is permanent I do the
procedure of
So to investigate this further I would need a log file of cups-browsed.
You get a log file if there is a line
DebugLogging file
in cups-browsed.conf
The log file will by default be created as
/var/log/cups/cups-browsed_log
Please attach your log file (from starting cups-browsed until
So to investigate this further I would need a log file of cups-browsed.
You get a log file if there is a line
DebugLogging file
in cups-browsed.conf
The log file will by default be created as
/var/log/cups/cups-browsed_log
Please attach your log file (from starting cups-browsed until
Concerning the scanning, I have done the following observation:
I have the HP OfficeJet Pro 8730.
I have removed all print queues using the "hp" CUPS backend (I print
with a driverless queue). With an HPLIP-based print queue my scanner is
always found.
1. Printer on the network
scanimage
In general, it looks like that the HPLIP guys at HP are not testing well
the GUI part. This caused the following bugs, all forwarded upstream but
no fixes from upstream yet, only distro patches in the Ubuntu Cosmic
package of HPLIP (3.18.7+dfsg1-2ubuntu2):
https://launchpad.net/bugs/1688684
Brian, if the user only wants to print with his printer (is it a
print-only device or a multi-function device with scanner) driverless
IPP printing works indeed, especially with HP devices. Then this is the
recommended solution.
Only for scanning one still needs drivers and in case of HP's
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
CUPS/IPP backend:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911340
Google Cloud Print backend:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911342
Print-to-File backend:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911345
Package: wnpp
Severity: wishlist
Owner: Till Kamppeter
* Package name: cpdb-backend-file
Version : 1.0.1
Upstream Author : Ayush Bansal
* URL : https://github.com/OpenPrinting/cpdb-backend-file
* License : MIT
Programming Lang: C
Description : Common
Package: wnpp
Severity: wishlist
Owner: Till Kamppeter
* Package name: cpdb-backend-gcp
Version : 1.1.0
Upstream Author : Abhijeet Dubey
* URL : https://github.com/OpenPrinting/cpdb-backend-gcp
* License : MIT
Programming Lang: C
Description : Common
Package: wnpp
Severity: wishlist
Owner: Till Kamppeter
* Package name: cpdb-backend-cups
Version : 1.1.0
Upstream Author : Nilanjana Lodh
* URL : https://github.com/OpenPrinting/cpdb-backend-cups
* License : MIT
Programming Lang: C
Description
Package: wnpp
Severity: wishlist
Owner: Till Kamppeter
* Package name: cpdb-libs
Version : 1.1.2
Upstream Author : Nilanjana Lodh
* URL : https://github.com/OpenPrinting/cpdb-libs
* License : MIT
Programming Lang: C
Description : Common Print Dialog
Thanks, but please get the patch from here:
https://github.com/OpenPrinting/ippusbxd
or
https://github.com/lathiat/avahi/issues/125
Your links were my first post of ippusbxd right after my GSoC student
has done this project, long before I decided to move the OpenPrinting
projects to GitHub.
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 04/09/18 21:20, Dimitri Chausson wrote:
Hello Brian,
thanks for your quick reply, following are the results:
$> grep -i cupsfilter /etc/cups/ppd/HP_DeskJet_3630_series.ppd
*cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip-hplip"
*cupsFilter: "application/vnd.cups-pdf 0
cups-filters 1.21.2 is released upstream now.
Till
Thank you very much for the test. So the problem is solved. I will do a
1.21.2 release soon so that a fixed package can be uploaded to Debian.
Till
Bernhard, thank for the patch. I have applied it now (and also done an
additional fix for DomainSocket) and committed it to the upstream GIT repo.
Please test.
Till
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
On 25/07/18 21:40, Brian Potkin wrote:
From what I read, ippserver in CUPS is experimental sample code that
upstream advises against using in a distribution.
https://github.com/apple/cups/issues/5141
https://github.com/apple/cups/issues/5222
Yes, therefore the introduction of the ippsample
I think so, please add a "Recommends: avahi-daemon".
By the way, cups-ipp-utils should get replaced by the independent
ippsample package. as these tools are now independently maintained by
the PWG (Printing Working Group). The "ippsample" package is at least in
Ubuntu Universe
Released 1.20.3 upstream now, containing said fix:
https://github.com/OpenPrinting/cups-filters/releases/tag/release-1-20-3
Package: dhelp
Version: 0.6.24
Hi,
dhelp uses pstotext to display PostScript files on a console or in a
terminal.
pstotext stopped working with the recent update to Ghostscript 9.22.
This is not only due to the deprecation of "-dDELAYBIND" in Ghostscript
(which was withdrawn in 9.23) but
(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
On 12/14/2017 02:54 PM, Brian Potkin wrote:
On Thu 14 Dec 2017 at 02:28:18 -0600, David Fries wrote:
On Tue, Dec 12, 2017 at 08:01:44PM +, Brian Potkin wrote:
5. 'lpstat -t' should show a print queue with an implicitclass URI
which has automatically been set up by cups-browsed, There
Can you please run the command
avahi-browse -v -t -r --all
and post its output here?
Please also edit /etc/cups/cups-browsed.conf, to have a line
DebugLogging file
without "#" in the beginning. Restart cups-browsed. Wait some seconds
and stop cups-browsed. Then attach the file
Bug reported upstream to HP (and to Ubuntu) as:
https://bugs.launchpad.net/debian/+source/hplip/+bug/1710378
Thank you very much for the patch.
I have applied it now to he upstream code of cups-filters (BZR rev. 7672).
Note that the error message
"Unable to create/modify CUPS queue (Success)!"
is actually caused by another bug which I had already fixed earlier. The
queue has actually been created
Fixed in cups-filters upstream, BZR rev. 7667, will be included in the
cups-filters 1.16.1 release.
Thank you for your bug report with backtrace.
Problem was an uninitialized pointer which made the crash always happen
when a BrowsePolled printer has no "Location" field in its IPP attributes.
This is all very strange.
What do you get if you run the command
driverless
This should make the printer's IPP URI appear. Now run
driverless [IPP URI] > out.ppd
with [IPP URI] replaced by the printer's IPP URI, the output of the
first command.
out.ppd then is a valid and working PPD for
On 07/17/2017 08:34 PM, brian m. carlson wrote:
It does not appear to fix the problem. The PPD that's generated is
identical and still contains the 600x2 resolution. I will lose access
to the printer tomorrow, unfortunately, so I'll be unable to test
further.
The actual change takes place
I have now added a fallback mechanism to the PPD generator in
cups-filters which does not accept resolutions < 75 dpi.
It is committed (rev. 7652) to the upstream BZR repository. Please test.
Till
It seems that the printer answers the wrong resolution (firmware bug).
Under the printer's attributes I have found:
DEBUG2: Attr: pwg-raster-document-resolution-supported
DEBUG2: Value: 600x2dpi
Please run the following command:
ipptool -tv ipp://copper.local:631/ipp/print
On 07/14/2017 11:38 AM, Roland Hieber wrote:
Hi,
On 13.07.2017 16:55, Till Kamppeter wrote:
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
1 - 100 of 322 matches
Mail list logo
