Bug#998408: "good password" advice in installer is still bad two years after this was reported

[Brian Potkin]

On Thu 07 Sep 2023 at 01:27:23 +0200, Philip Hands wrote:

> Jonathan Kamens  writes:
> 
> > Oh, I see now that the fact that the installer shouldn't recommend 
> > changing one's password regularly was also reported previously, in bug 
> > #868869.
> 
> Also, in #656509 (in which Cyril states that the effort of translating a
> new message outweighs the importance of the change).
> 
> I've no idea if that justification for inaction still stands, but I
> thought this would make a nice little example for the use of the
> salsa-CI pipeline (and my branch2repo variant of that), so here's an MR:
> 
>   https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7
> 
> and here's a screenshot of what the change looks like:
> 
>   https://openqa.debian.net/tests/185853#step/passwords/1
> 
> I'm not 100% happy with the wording (and the underlines around 'should'
> need to go) so I'm very likely to tweak it tomorrow.
> 
> Suggestions for improvement welcome, although be aware that given the
> resistance to fixing this in the past, it's always possible such a
> change will also be deemed unjustified now.
> 
> I think it's probably about time we fixed it, since even the civil
> servants in the UK have stopped recommending password changes by now,
> and they tend to make such changes at least a decade late. ;-)

The password strength advice in d-i has been there from the year dot.
Irrespective of what GCHQ and others say now, it was a load of nonsense
then and remains so.

The vast majority of users ignore it; some might schedule a password
change at the same time they change the locks on all outside doors of
their residence or on their cars.

Debian has no need to offer password advice (as opposed to roo vs sudo).
So leave it there as a historical oddity or delete the d-i advice. The
latter route does not involve anyone in any great effort to maintain
the staus quo.

-- 
Brian.

Bug#1042570: ippsample: ippserver and ippfind are non-functional

[Brian Potkin]

Package: ippsample
Version: 0.0~git20220607.72f89b3
Severity: grave
Justification: renders package unusable


In spite of having the printing system wiped out (Bug#1040699) I installed
this package to try out ippserver.

brian@test-new:~$ /usr/sbin/ippserver -c $HOME/pdfsave -f application/pdf 
"Print to PDF"
/usr/sbin/ippserver: error while loading shared libraries: libcups.so.3: cannot 
open shared object file: No such file or directory
brian@test-new:~$

ippfind produces the same output.

Regards,

Brian.

Bug#1039983: cups: CMYK capable printer does not print in colour

[Brian Potkin]

tags 1039983 upstream
retitle 1039983 CMYK capable printer does not print in colour
thanks



On Fri 30 Jun 2023 at 17:56:08 +0200, Kerstin Hoef-Emden wrote:

> Package: cups
> Version: 2.4.2-3
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> Upgrade from bullseye to bookworm
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> First of all, the printer drivers for my printer (Kyocera FS-C5250dn) were not
> anymore available in the printers list. The original Kyocera PPD files were
> still present in the file system. I chose them by browsing the file system.
> Although the printer was now identified as capable of doing CMYK and it was 
> set
> to color in the cups browser interface. I also tried to change the setting in
> printer.conf a) by hand to printer-color-mode CMYK and I tried the command
> lpoptions -p Kyocera -o printer-colormode=CMYK.
> 
>* What was the outcome of this action?
> It did not work, the printer still prints only Black & White and I am not able
> to change the setting in printer.conf.
> 
>* What outcome did you expect instead?
> 
> For sure I want my color printer to print color again.

THank you for your report,  Kerstin. Your issue sounds like the on at

  https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1971242

Does the lpadmin workaround do anything for you?

Regards,

Brian.

Bug#1033625: closed by Brian Potkin (Re: Bug#1033625:)

[Brian Potkin]

On Thu 30 Mar 2023 at 15:54:09 +0200, Johan Kröckel wrote:

> Hi Brian,
> 
> thanks for your help. But isn't it still a bug that cups is creating a
> printer(-queue) that not only does not work, but also when using it opens
> connections to the printer for hours? I think about the situation, that you
> have many bookworm clients in the network, this could amount to a denial of
> service.
> 
> I deleted the not working Kyocera_ECOSYS_M5526cdw but cups keeps recreating
> it when I connect to the corresponding network.

The auto-creation of the queue (the one shown by 'lpstat -t' and that keeps
coming back after deletion) is done by cups-browsed, not by CUPS. Let's try
this:

Purge cups-browsed with

 apt purge cups-browsed

Then do 

 rm  rm /var/cache/cups/*

(the files will be regenerated) and restart cups.

 systemctl restart cups

'lstsat -l -e' should show a printer name. Can it be used to print? 'lpstat -t'
should not have implicitclass and should show the manually set up printer,

Cheers,

Brian.

Bug#1033616: cups prepends job number to job-name so job names near 255 characters may be too long

[Brian Potkin]

On Tue 28 Mar 2023 at 18:45:02 +0200, John Hughes wrote:

> Package: cups
> Version: 2.3.3op2-3+deb11u2
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> I printed a page from firefox with a very, very long URL.  Firefox used the 
> first 255 bytes of the URL as the job name.
> 
>* What was the outcome of this action?
> 
> The job mysteriously didn't print.  Lookin in the cups log (with debug on) I 
> found the lines:
> 
> D [28/Mar/2023:18:14:44 +0200] [Job 365] job-name nameWithoutLanguage 365 - 
> https://xxx//xx
> 
> D [28/Mar/2023:18:27:36 +0200] [Job 369] Validate-Job: 
> client-error-request-value-too-long (client-error-request-value-too-long)
> 
> notice how the job name passed to cups ("https://xxx...;) is shorter than 255 
> characters, but when the job number "365 - " is prepended it is longer tnan 
> 255 characters and so overflows.
> 
>* What outcome did you expect instead?
> 
> That my print job be printed rather than just geting stuck in the print queue 
> forever.
> 
> How to reproduce:
> 
>   lp -o 
> 'job-name=https://xxx//xx'

Thank you for your report, John.

I think it would be better if you took this upstream:

  https://github.com/OpenPrinting/cups/issues

Regards,

Brian.

Bug#1033625:

[Brian Potkin]

On Wed 29 Mar 2023 at 11:36:50 +0200, Johan Kröckel wrote:

> root@stockholm:~#  lpstat -l -e
> Kyocera_ECOSYS_M5526cdw network none
> ipps://Kyocera%20ECOSYS%20M5526cdw._ipps._tcp.local/

Printiing should take place with

  lp -d Kyocera_ECOSYS_M5526cdw /etc/nsswitch.conf

Does it?

> root@stockholm:~# driverless
> ipps://Kyocera%20ECOSYS%20M5526cdw._ipps._tcp.local/

A print queue can also be manually set up by

  lpadmin -p M5526cdw -v "ipps://Kyocera%20ECOSYS%20M5526cdw._ipps._tcp.local/" 
-E -m everywhere

Test printing with

  lp -d M5526cdw /etc/nsswitch.conf

Cheers,

Brian.

Bug#1033625: cups constantly without timeout connects to network printer, does not print

[Brian Potkin]

On Tue 28 Mar 2023 at 23:01:47 +0200, Johan Kröckel wrote:

> Package: cups
> Version: 2.4.2-2
> Severity: important
> X-Debbugs-Cc: johan.kroec...@gmail.com
> 
> I am using a Kyocera Ecosys m5526cdw over the network. Printing
> stopped working (worked with this version before).
> 
> Now when I try to start a print job cups ends with a message "Der
> Druckauftrag wurde nicht angenommen.". BUT:
> 
> Now cups connects to the printer (LED on printer lights up as long as
> the pc is on) but nothing is printed. When I reboot, the LED stops to
> blink as long as the system is not completely booted, then the
> connection starts again.
> 
> After running cupsctl --debug-logging, error_log grows by around 30
> megabytes per hour.

Thank you for your report, Johan.

Please provude outputs for

  lpstat -l -e
  lpstat -t
  avahi-browse -rt _ipp._tcp
  avahi-browse -rt _uscan._tcp
  driverless
  lpoptions -p PRINTER_NAME

avahi-browse is in the avahi-utils package.

Regards,

Brian.

Bug#1031233: hplip: hp-plugin unable to download plugin

[Brian Potkin]

tags 1031233 upstream
merge 1031233 1029459
severity 103123 important
thanks



On Mon 13 Feb 2023 at 09:20:49 -0800, Curtis Dean Smith wrote:

> Package: hplip
> Version: 3.22.10+dfsg0-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: smit...@hush.com
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> The cups hplip suddenly stopped working and initiated the plugin
>download, which failed.
>  
> 
> -- Package-specific info:
> Saving output in log file: /home/cds/hp-check.log
> 
> HP Linux Imaging and Printing System (ver. 3.22.10)
> Dependency/Version Check Utility ver. 15.1
> 
> Copyright (c) 2001-18 HP 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.
> 
> Note: hp-check can be run in three modes:
> 1. Compile-time check mode (-c or --compile): Use this mode before compiling 
> the
> HPLIP supplied tarball (.tar.gz or .run) to determine if the proper 
> dependencies
> are installed to successfully compile HPLIP.  
>   
> 2. Run-time check mode (-r or --run): Use this mode to determine if a distro  
>   
> supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball 
>   
> has the proper dependencies installed to successfully run.
>   
> 3. Both compile- and run-time check mode (-b or --both) (Default): This mode  
>   
> will check both of the above cases (both compile- and run-time dependencies). 
>   
> 
> Check types:  
>   
> a. EXTERNALDEP - External Dependencies
>   
> b. GENERALDEP - General Dependencies (required both at compile and run time)  
>   
> c. COMPILEDEP - Compile time Dependencies 
>   
> d. [All are run-time checks]  
>   
> PYEXT SCANCONF QUEUES PERMISSION  
>   
> 
> Status Types:
> OK
> MISSING   - Missing Dependency or Permission or Plug-in
> INCOMPAT  - Incompatible dependency-version or Plugin-version
> 
> Traceback (most recent call last):
>   File "/usr/bin/hp-check", line 860, in 
> dep =  DependenciesCheck(MODE_CHECK,INTERACTIVE_MODE,ui_toolkit)
>^
>   File "/usr/bin/hp-check", line 175, in __init__
> self.core = CoreInstall(mode, ui_mode, ui_toolkit)
> ^^
>   File "/usr/share/hplip/installer/core_install.py", line 240, in __init__
> self.passwordObj = password.Password(ui_mode)
>^^
>   File "/usr/share/hplip/base/password.py", line 94, in __init__
> self.__readAuthType()  # self.__authType
> ^
>   File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
> distro_name = get_distro_std_name(os_name)
>   ^^^
> NameError: name 'get_distro_std_name' is not defined. Did you mean: 
> 'get_distro_name'?

Thank you for your report, Curtis. This looks like #1029459:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029459

A nice confirmation that something is amiss.

Regards,

Brian.

Bug#1030043: hplip-gui: traceback when launching hp-toolbox

[Brian Potkin]

tags 1029459 upstream
severity 1029459 important
thanks




On Mon 30 Jan 2023 at 17:27:10 +0100, Julien Patriarca wrote:

> Package: hplip-gui
> Version: 3.22.10+dfsg0-1
> Severity: grave
> Tags: patch
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> Trying to launch hp-toolbox software, got this output:
> 
> Traceback (most recent call last):
>   File "/usr/bin/hp-toolbox", line 280, in 
> toolbox = ui.DevMgr5(__version__, device_uri,  None)
>   ^^
>   File "/usr/share/hplip/ui5/devmgr5.py", line 238, in __init__
> core =  CoreInstall(MODE_CHECK)
> ^^^
>   File "/usr/share/hplip/installer/core_install.py", line 240, in __init__
> self.passwordObj = password.Password(ui_mode)
>^^
>   File "/usr/share/hplip/base/password.py", line 94, in __init__
> self.__readAuthType()  # self.__authType
> ^
>   File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
> distro_name = get_distro_std_name(os_name)
>   ^^^
> NameError: name 'get_distro_std_name' is not defined. Did you mean: 
> 'get_distro_name'?
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I patched the password.py file with the correct function name and 
> delete the os_name parameter when being called.
> 
>* What was the outcome of this action?
> 
> Positive. The hp-toolbox launched succesfully.

Thank you for your report, Julien. This issue does not
appear too dissimilar to #1029459:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029459

Reducing severity because not all hp-* utilities are
affected. hp-wificonfig, for instance.

Regards,

Brian.

Bug#1029779: cups: Can't add printers after fresh install.

[Brian Potkin]

tags 1029779 unreproducible
thanks



On Sat 28 Jan 2023 at 13:11:20 +0100, Ignacio Encinas Rubio wrote:

> Yes. Originally root and user had same password. Couldn't login and luckily
> found that old issue, changed root password and then the problem was
> solved.
> 
> I'm unable to reproduce this issue on another Debian machine I have which
> has the same cups package but has been updated more recently.
> 
> Right now I don't have access to the machine that had the problem, but I'll
> try to reproduce the error again on monday changing the password to the old
> one.
> 
> Let me know if there is any other information I could provide that would be
> useful to you.

I used an up-to-date unstable and made the root and user
passwords the same. Logged out and back in. I was able to
complete administrative tasks. Let's see how you go on.

Cheers,

Brian.

Bug#1029779: cups: Can't add printers after fresh install.

[Brian Potkin]

tags 1029779 moreinfo
thanks



On Fri 27 Jan 2023 at 15:53:28 +0100, Ignacio Encinas Rubio wrote:

> Package: cups
> Version: 2.4.2-1+b2
> Severity: important
> X-Debbugs-Cc: iencinasru...@gmail.com
> 
> Dear Maintainer,
> 
> After freshly installing cups I tried adding a printer, but I couldn't
> because login kept failing. Luckily enough after random googling I 
> stumbled upon this GitHub issue (https://github.com/apple/cups/issues/4840).
> 
> I changed the root password, and after that I could login.
> 
> It's the first bug report I ever do, so sorry if the severity field
> results missleading or any other inconvenience. 
> 
> Thank you for your work.


Thank you for your report, Ignacio.

Some clarification, please. Are you saying you origianally
had root and user with identical passwords?

Regards,

Brian.

Bug#1029459: hp-plugin crashes when trying to download plugin with error NameError: name 'get_distro_std_name' is not defined. Did you mean: 'get_distro_name'?

[Brian Potkin]

forwarded 1029459 https://bugs.launchpad.net/hplip/+bug/2003739
thanks




> On Mon, Jan 23 2023 at 04:57:16 PM +00:00:00 +00:00:00, Brian Potkin
>  wrote:

> > My attempt with
> > 
> >   sh -i hplip-3.22.10-plugin.run
> > 
> > failed over an ssh link. This is an upstream issue.
> > get_distro_std_name is not used in hplip-3.22.6.
> > Please report at
> > 
> >   https://bugs.launchpad.net/hplip/+bugs
> > 
> 
> If you are already familiar with launchpad, can you file it?

OK.

> > I would query the severity of grave rather than
> > imortant. Plugin files can be installed with
> > 
> >   sh hplip--plugin.run --tar vxf
> >   python3 installPlugin.py
> > 
> 
> Lowered severity to important. Though we probably have to document it
> somewhere more visible until this is fixed.

Thanks. The technique is not well knwn but it is viable.

Regards,

Brian.

Bug#1029459: hp-plugin crashes when trying to download plugin with error NameError: name 'get_distro_std_name' is not defined. Did you mean: 'get_distro_name'?

[Brian Potkin]

On Mon 23 Jan 2023 at 01:39:46 +0530, Pirate Praveen wrote:

> Package: hplip
> Version: 3.22.10+dfsg0-1
> Severity: grave
> Justification: makes it unusable
> 
> $ hp-plugin
> 
> HP Linux Imaging and Printing System (ver. 3.22.10)
> Plugin Download and Install Utility ver. 2.1
> 
> Copyright (c) 2001-18 HP 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.
> 
> 
> HP Linux Imaging and Printing System (ver. 3.22.10)
> Plugin Download and Install Utility ver. 2.1
> 
> Copyright (c) 2001-18 HP 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.
> 
> QSocketNotifier: Can only be used with threads started with QThread
> Checking for network connection...
> Downloading plug-in from:
> Traceback (most recent call last):
>   File "/usr/share/hplip/ui5/plugindialog.py", line 248, in
> NextButton_clicked
> status, download_plugin_file, error_str =
> self.pluginObj.download(self.plugin_path,self.plugin_download_callback)
> 
> ^^^
>   File "/usr/share/hplip/installer/pluginhandler.py", line 257, in download
> core = core_install.CoreInstall()
>^^
>   File "/usr/share/hplip/installer/core_install.py", line 240, in __init__
> self.passwordObj = password.Password(ui_mode)
>^^
>   File "/usr/share/hplip/base/password.py", line 94, in __init__
> self.__readAuthType()  # self.__authType
> ^
>   File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
> distro_name = get_distro_std_name(os_name)
>   ^^^
> NameError: name 'get_distro_std_name' is not defined. Did you mean:
> 'get_distro_name'?
> Aborted

Thank you for you report, Pirate Praveen.

My attempt with

  sh -i hplip-3.22.10-plugin.run

failed over an ssh link. This is an upstream issue.
get_distro_std_name is not used in hplip-3.22.6.
Please report at

  https://bugs.launchpad.net/hplip/+bugs

I would query the severity of grave rather than
imortant. Plugin files can be installed with

  sh hplip--plugin.run --tar vxf
  python3 installPlugin.py

Regards,

Brian.

  
 

Bug#1022974: hplip: Needs sudo but does not depend on it

[Brian Potkin]

tags 1022974 moreinfo
thanks



On Fri 28 Oct 2022 at 19:11:36 +0300, Teemu Ikonen wrote:

> Package: hplip
> Version: 3.22.6+dfsg0-1
> Severity: normal
> X-Debbugs-Cc: tpiko...@gmail.com
> 
> When installing the non-free plugin with hp-plugin, the installer
> authenticates using 'sudo'. If sudo is not installed, the password
> prompt always reports an invalid password error.
> 
> hplip package should depend on sudo. Bonus points for checking that the
> sudo configuration works before starting the installation.

Thank you for your report, Teemu. Please inicate whether Debian was
installed with or without a root account.

Regards,
Brian.

Bug#1019593: hp-plugin: Failure to download plugin

[Brian Potkin]

On Wed 14 Sep 2022 at 21:04:41 +0200, martin f krafft wrote:

> Thanks Brian for your quick response. Yeah, it's cool that I can use 
> the printer for driverless printing, but unfortunately, the scanning 
> functionality still requires the plugin.

On unstable libsane1 installs the recommended sane-airscan. This
gives driverless scanning, which is supported by your deice. Color
me perplexed! Please give

 scanimage -L
 airscan-discover

> It is also true that the issue seems to be in code downloaded 
> on-the-fly from upstream, so you're right in closing the bug.

Coincidentally; another two reports:

 https://bugs.launchpad.net/hplip/+bug/1989508
 https://bugs.launchpad.net/hplip/+bug/1989592

Cheers,

Brian.

Bug#1018265: cups picks manual tray on HP Color LaserJet M252dw

[Brian Potkin]

On Sun 28 Aug 2022 at 11:24:51 +0200, Steinar Bang wrote:

> Package: cups
> Version: 2.3.3op2-3+deb11u2
> Severity: important
> X-Debbugs-Cc: s...@dod.no

Thank you for your report, Steinar.
 
> Dear Maintainer,
> 
> When printing, the printer picks what it calls "Tray 1", which is a slot in 
> the
> front of the printer, where sheets can be fed one at a time. After feeding a
> sheet in, I have to press "OK" on the printer's front panel display.
> 
> This has to be repeated for each sheet printed and makes it cumbersome to use
> the printer.
> 
> I have opened "System->Administration->Print Settings" from the debian menu.
> 
> I have double clicked on the printer HP_Color_LaserJet_Pro_M252dw_501595_
> 
> In "Printer Properties"->"Print Options" there is the setting "Media source".
> 
> "Media source" is a dropdown with the values
>  Automatic
>  Manual
>  Tray 1
>  Tray 2
> 
> I have tried the settings "Automatic" (the default) and "Tray 1" and
> "Tray 2" and all of them uses the manual tray, which the printer display
> calls "Tray 1".
> 
> There was no change. The printer still printed from the manual tray
> 
> I had expected "Tray 2" and "Automatic" to pick "Tray 2", which is the regular
> paper tray.
> 
> Cups report the printer as HP Color LaserJet Pro M252dw, driverless, cups-
> filters 1.28.7 (so driverless.ppd is in use. This is a network printer with
> PostScript).
> 
> I don't know when this behaviour started, but I can't remember needing to feed
> paper manually in December/November 2021, when I printed the Christmas 
> letters.

Please take this issue upstream:

  https://github.com/OpenPrinting/cups-filters/issues

would be worth a try. A short explanation of the issue plus a link
to the Debian bug report should be sufficient.

Regards,

Brian.

Bug#1018085: hplip fails to setup wired printer HP P 1102w

[Brian Potkin]

On Thu 25 Aug 2022 at 08:41:20 -0500, William Melgaard wrote:

> Package: hplip
> Version: 3.21.2+dfsg1-2
> Severity: normal
> X-Debbugs-Cc: piob...@mindspring.com

Thank you for your report, William.
 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> print driver failed after upgrade to bullseye

TBH, this issue gives the impression of being a user support issue.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Instlled latest hplip; deleted existing driver and installed printer
> HP Laserjet Pro P1102w

It hoped by "latest hplip" the version for Debian 11 was installed?

>* What was the outcome of this action
> The install insists on the installation of a proprietary plugin.
> However, attempts to install that plugin from HP CD fails because the
> workstation does not have a WiFi port HPLIP does offer the option of
> USB vs WiFi connection. However, chosing USB appears ineffectual. The
> setup still insists that the plugin is missing.

Upstream offen advise the following technique:

 * Download the plugin for your HPLIP version from
   https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/
 * Install the plugin with 'sh DOWNLOADED_PLUGIN'

>* What outcome did you expect instead?
> Successful test print

That should be possible with a correct setup. Please give

  lpstat -t
  lpinfo -v
  lpinfo -m | grep p1102w

Regards,

Brian.

Bug#1017973: cups-browsed: Unable to print after resume from suspend

[Brian Potkin]

tags 1017973 upstream
thanks




On Tue 23 Aug 2022 at 19:14:46 +0930, Josh Heidenreich wrote:

> Package: cups-browsed
> Version: 1.28.7-1+deb11u1
> Severity: important
> X-Debbugs-Cc: josh.sickm...@gmail.com

Thank you for your report, Josh

> Dear Maintainer,
>
> When resuming from suspend (such as re-opening the lid of my laptop), printing
> over the network no longer works. I receive the following error:
> 
> No destination host name supplied by cups-browsed for printer "name",
> is cups-browsed running?

This is a message that crops up in other bug reports but not necessarily
involving suspend. See

 https://github.com/OpenPrinting/cups-filters/issues/97

> Restarting the service (i.e. sudo service cups-browsed restart) resolves the
> issue and printing then works. Attempting other fixes does not work; I've
> tried starting and stopping the printer within the CUPS web interface for
> example.
> 
> Note that my device needs to re-connect network after a resume. I of course
> wait for this to finish before attempting printing.
> 
> The printer devices do show up within applications. I don't have any printers
> "installed" as such, only using auto-detection. I regurally switch networks
> between home and office. Device is a Dell XPS 13 model 9370.

Which application? You could try purging (or stopping) cups-browse. The
printers should still show up, even after resuming from suspend.
 
> I've examined the debian changelog an did not see any notable package changes
> between 'stable' and 'unstable' versions of this package.
> 
> I have also examined the upstream changes for each of the versions, and have
> found one possible fix, released in v1.28.9:
> 
> https://github.com/OpenPrinting/cups-filters/pull/360
> "utils/cups-browsed.service: Add network-online.target"
> 
> This change alters the SystemD configuration to depend on the network being
> online.

AFAICT, #360 involves the legacy CUPS protocol, which I doubt very much
you are using.
 
> I've logged this bug report as I consider both printing and suspend/resume
> to be important features. Futhermore, new users would consider printing to
> be "broken" if they had closed the lid of their laptop even a single time
> prior to printing.

TBH, I think your best course of action is to take this upstream.

 https://github.com/OpenPrinting/cups-filters/issues

Regards,

Brian.

Bug#980974: apparmor blocks cups backend outgoing network connections

[Brian Potkin]

On Wed 17 Aug 2022 at 20:47:24 +0200, Christian Boltz wrote:

> Hello,
> 
> denials for capabilty net_admin are often a sign that a service uses 
> systemd libraries on startup, and these systemd libraries do funny[tm] 
> things. In these cases the net_admin capability is not really needed.
> 
> See https://bugzilla.opensuse.org/show_bug.cgi?id=1196850#c3 for the 
> technical details. (Yes, I'm aware that this bugreport is for Samba, not 
> cups - but I'm somewhat sure that cups uses the same systemd libraries 
> on startup.)
> 
> I have to admit that I'm only a cups user, but I'd be surprised if it 
> really needs capability net_admin.

In capabilities(7) network-related operations for CAP_NET_ADMIN include

  bind to any address for transparent proxying;
  enabling multicasting;

I am not sue these are the relevant operations in this case but I am
suue that Debian 11 introduced ipp-usb as a recommended package for
cups-daemon. ipp-usb effectively implements a HTTP reverse proxy:

  https://github.com/OpenPrinting/ipp-usb

Twp clues? Putting them together I purged ipp-usb and the deniel for
capabilty net_admin disappears from the journal when cups is restarted.
Perhaps this could be tested by others?

> To find out if it's really needed or just "systemd noise", can you please 
> explicitely deny net_admin and test if printing still works? To do this, 
> add
>   deny capability net_admin,
> to /etc/apparmor.d/local/usr.sbin.cupsd   This will a) deny it and b) 
> silence the logging. Then reload the profile with
> systemctl reload apparmor
> 
> I'd also recommend to
> aa-enforce cupsd
> (in theory deny rules get enforced even in complain mode, but better 
> safe than sorry)
> 
> 
> If printing doesn't work with the deny rule added, please try if it 
> works if you allow the capability:
> capability net_admin,
> (and remove the deny rule).

I don't notice any degradation in printing to printers over the network.
USB printing (using IPP-over-USB) wasn't tested, but has always worked
for me in the past.

My tentative conclusion is that cupsd's desire to access capabilty
net_admin is legitimate. OTOH, denying it doesn't appear to affect my
printing here, but more testing is needed

Cheers,

Brian.

Bug#977813: cupsd requests net_admin capability, but AppArmor denies

[Brian Potkin]

On Mon 21 Dec 2020 at 12:25:21 +0100, Jörg Sommer wrote:

> Package: cups-daemon
> Version: 2.3.3op1-3
> Severity: normal
> 
> Hi,
> 
> since the upgrade of cups-daemon from 2.3.3-4 to 2.3.3op1-1 I see these
> message in my log:
> 
> ```
> kernel: audit: type=1400 audit(1608535286.330:113): apparmor="DENIED" 
> operation="capable" profile="/usr/sbin/cupsd" pid=479747 comm="cupsd" 
> capability=12  capname="net_admin"
> ```
> 
> I'm unsure to allow it in AppArmor, because it's a very privileged
> capability:
> 
> > CAP_NET_ADMIN
> >Perform various network-related operations:
> >* interface configuration;
> >* administration of IP firewall, masquerading, and accounting;
> >* modify routing tables;
> >* bind to any address for transparent proxying;
> >* set type-of-service (TOS);
> >* clear driver statistics;
> >* set promiscuous mode;
> >* enabling multicasting;
> >* use setsockopt(2) to set the following socket options:  SO_DE‐
> >  BUG,  SO_MARK, SO_PRIORITY (for a priority outside the range 0
> >  to 6), SO_RCVBUFFORCE, and SO_SNDBUFFORCE.

Thank you for your report, Jörg. Please see #980974:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980974

Regards,

Brian.

Bug#980974: apparmor blocks cups backend outgoing network connections

[Brian Potkin]

On Mon 25 Jan 2021 at 23:21:20 +, Brian Potkin wrote:

[...]

> Triaging this report, Chris, but my knowledge of apparmor is very
> limited. However, I have a minimal unstable installation (base
> system plus only cups) and can reproduce this behaviour. The last
> line (but not the first) disappears when cups-browsed is purged.

JFTR. Regarding the apparmor profile and cups-browsed, there is
Ubuntu bug #1897369:

 https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1897369

Till Kamppeter (the author of cups-browsed) says

  I did not have anything to control the priority in the source code
  of cups-browsed, I also did not find anything in the packaging of
  cups-filters. I also do not see any security risk in priority
  changing, it can only make the system faster or slower.

Then there is Debian bug #1016622:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016622

which basically says - don't worry about it. Perhaps it could be the
same situation for cupsd.

Cheers,

Brian.

Bug#1004734: "usblp0: removed" when printing via USB on Canon LBP-810

[Brian Potkin]

tags 1004734 moreinfo
thanks



On Tue 01 Feb 2022 at 13:30:58 +0100, Yvan Masson wrote:

> Package: cups
> X-Debbugs-Cc: y...@masson-informatique.fr
> Version: 2.3.3op2-7
> Severity: normal
> 
> Dear Maintainers,
> 
> I tried to print on an old Canon LBP-810 with Debian testing, connected via
> USB. This printer is known to be working with parallel port.
> 
> The printer is properly detected:
> 
> févr. 01 12:05:29 e7440 kernel: usb 2-2: new full-speed USB device number 5
> using xhci_hcd
> févr. 01 12:05:29 e7440 kernel: usb 2-2: New USB device found,
> idVendor=04a9, idProduct=260a, bcdDevice= 1.00
> févr. 01 12:05:29 e7440 kernel: usb 2-2: New USB device strings: Mfr=1,
> Product=2, SerialNumber=3
> févr. 01 12:05:29 e7440 kernel: usb 2-2: Product: Canon CAPT USB Printer
> févr. 01 12:05:29 e7440 kernel: usb 2-2: Manufacturer: Canon
> févr. 01 12:05:29 e7440 kernel: usb 2-2: SerialNumber: 541868YO
> févr. 01 12:05:29 e7440 kernel: usblp 2-2:1.0: usblp0: USB Bidirectional
> printer dev 5 if 0 alt 0 proto 2 vid 0x04A9 pid 0x260A
> 
> It is then properly added to the CUPS system, but when I try to print
> something, the following appears in kernel logs:
> 
> févr. 01 12:05:34 e7440 kernel: usblp0: removed
> févr. 01 12:05:34 e7440 kernel: usblp 2-2:1.0: usblp0: USB Bidirectional
> printer dev 5 if 0 alt 0 proto 2 vid 0x04A9 pid 0x260A
> févr. 01 12:05:35 e7440 kernel: usblp0: removed
> 
> And the printer does not print.
> 
> I already tried settings CUPS options "usb-unidir-default" and
> "usb-no-reattach-default", as suggested in [1], without luck.
> 
> Please apologize if this issue does not belong to cups.
> 
> Regards,
> Yvan
> 
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=873123

Thank you for your report, Yvan.

I may have recommended looking at

  https://wiki.debian.org/CUPSDebugging#usb

but you seem to have tried something similar.

What driver (PPD) are you using and are you now printing?

Regards,

Brian.

Bug#970327: cups: make apparmor abort at startup

[Brian Potkin]

tags 970327 moreinfo
thanks



On Mon 14 Sep 2020 at 19:44:21 +0200, JP wrote:

> Package: cups
> Version: 2.2.10-6+deb10u3
> Severity: normal
>
> Dear Maintainer,
>
> When looking for apparmor "denied" messages I found that apparmor is not
> running ant cannot start as an error lies in the usr.bin.cups file. When I use
> the simple parser :
> apparmor_parser -vQ usr.sbin.cupsd
> I get the message :
> AppArmor parser error for usr.sbin.cupsd in usr.sbin.cupsd at line 173: syntax
> error, unexpected TOK_CLOSE, expecting TOK_END_OF_RULE
> If I try to start apparmor through systemctl I get an abort, as "normal"
> nothing to see in systemctl status apparmor, except that something get wrong
> ...
> I remove "usr.bin.cupsd" from /etc/apparmor.d and all is clear ...
> systemctl restart apparmor is clean and apparmor is running.

Thank you for your report, JP.

On bullseye and bookworm I get:

 root@sidt630:~# apparmor_parser -vQ /etc/apparmor.d/usr.sbin.cupsd
 Cached load succeeded for "/var/cache/apparmor/c08a2770.0/usr.sbin.cupsd".
 root@sidt630:~#

Please would you investigate?

Regards,

Brian.

Bug#1009146: cups Segmentation fault

[Brian Potkin]

tags 1009146 patch
forwarded 1009146 https://github.com/OpenPrinting/cups/issues/457
thanks


On Thu 07 Apr 2022 at 19:55:06 +0300, Дмитрий Тихомиров wrote:

> Package: cups 
> Version: 2.3.3 
> 
> Hi. 
> 
> Error message: Segmentation fault 
> 
> To reproduce this bug we just need to run command "lprm -P". In normal way it 
> must finish with output of available commands . 
> Technical description: Program lprm call function main(file lprm.c:30). In « 
> if ((instance = strchr (name, ' / ' )) != NULL ) » (file lprm.c:87) when we 
> send "-P" the program will received Segmentation fault . 
> 
> System information: Linux debian 5.10.0-12-amd64 #1 SMP Debian [ 
> callto:5.10.103-1 (2022-03-07 | 5.10.103-1 (2022-03-07 ] ) x86_64 GNU/Linux 
> libc-2.31.so 
> 
> CWE identifier for this bug: CWE-20: Improper Input Validation 
> 
> Way to fix this bug: change it " else { i ++; name = argv[i]; }" (file 
> lprm.c:82-86) to this "i ++; if (i >= argc) { _cupsLangPrintf(stderr, _("%s: 
> Error - expected username after \"-P\" option."), argv[0]); usage(); }" . 
 
Thank you for your report, Dmitriy. 

I can reproduce the behaviour with "lprm -P" on cups 2.4.2-1+b1.
Forwarded upstream.

Cheers,

Brian.

Bug#995149: cups-filters: Printing sometimes fails due to log message in PS output.

[Brian Potkin]

On Mon 27 Sep 2021 at 09:06:50 +0200, Daniel Höpfl wrote:

> Package: cups-filters
> Version: 1.28.7-1
> Severity: important
> Tags: upstream patch
> X-Debbugs-Cc: deb...@hoepfl.de

Thank you for your report, Daniel.
 
> Dear Maintainer,
> 
> TL;DR: There is a upstream bug/patch that solves the issue.
> See 
> 
> When printing some PDF files, using the Debian server as a remote print 
> queue, foomatic-rip sometimes produces an error message "Invalid page range: 
> ...". This message is sent to stdout instead of the log file.
> 
> Due to this log message, the PostScript that is sent to stdout contains 
> invalid command sequences.
> 
> The patch for upstream solves this issue.
> 
> I verified it by replacing the 'I' of the message in the foomatic-rip binary 
> with a '\0'
> 
> I verified that the bug has not been fixed in the source of the 
> testing/unstable branches:
> 
> filter/foomatic-rip/options.c:printf("Invalid page range: %s\n", 
> tok);
> 
> Please note that the very same error also applies to the foomatic-filters 
> package.

Fixed in cup-filters V1.28.11. Closing in the present version.

Cheers,

Brian.

Bug#908500: cups-browsed: Please consider making cups-browsed a Suggests:

[Brian Potkin]

On Thu 13 Dec 2018 at 20:04:31 +0100, Till Kamppeter wrote:

[...]

> To solve all the problems with the print dialogs I have started the Common
> Print Dialog Backends project in 2017. If Debian adopts it we will at some
> time really be able to work without cups-browsed.
> 
> See
> 
> https://github.com/OpenPrinting/cpdb-libs
> https://github.com/OpenPrinting/cpdb-backend-cups
> https://github.com/OpenPrinting/cpdb-backend-gcp
> https://github.com/OpenPrinting/cpdb-backend-file
> 
> and
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911340
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911342
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911345
> 
> These will centralize the communication with the print systems so that the
> print dialogs do not need to do this and do not need to be adapted to every
> change in print technology.

A CPD certainly looks like a good way forward. Meanwhile, I'll record
what I observe as the present situation with print dialogs using
GTK3 (libgtk-3-0), Qt (libqt5printsupport5 ) and LibreOffice.

Firefox 102.1.0esr
--

1. Opening "Print using the system dialog..." sees the network printers
   enumerated.
2. Selecting an entry leads to the formation of a temporary queue and
   the appearance of printer attributes in the dialog.
3. While the dialog is open, the temporary queue is restablished every
   minute, as shown by 'lpstat -a'.
4. After printing, the temporary queue takes about a minute to disappear.
5. Verdict: 10/10.


Okular 4:22.04.3-1
--

1. Opening the print dialog sees the network printers enumerated.
2. Selecting an entry does not lead to the formation of a temporary
   queue.
3. Printer attributes do not appear in the dialog. Under Options/Options
   Duplex-capableprinters are not recorded as such and Print Quality is
   absent from Properties/Advanced (the tab is greyed out).
4. Print and the printer attributes become available via the formation
   of a temporary queue. But re-open the dialog within a minute to gain
   access to the queue!
5. Verdict: 1/10.


Libreoffice 1:7.4.0~rc3-1
-

1. Opening the print dialog sees the network printers enumerated.
2. Selecting an entry does not lead to the formation of a temporary
   queue.
3. Printer attributes do not appear in the dialog. Page sizes bear little
   relationship to reality, there is a pretend option for printing in
   duplex and Print Qualty is nowhere to be seen.
4. Print and the printer attributes become available via the formation
   of a temporary queue that lasts a minute. But a twist on Qt! Attributs
   are kept in memory and only disappear when Libreoffice is closed.
5. Verdict: 3/10 (for ingenuity).


That's on Debian. Maybe things are different elsewhere.

Cheers,

Brian.

Bug#1017408: cups 2.4.2-1+b1 and changelog.Debian

[Brian Potkin]

Package: cups
Version: 2.4.2-1+b1
Severity: normal


cups was updated on my unstable machine a few days ago. changelog.Debian
hasn't any details about it. Am I missing something?

Regards,

Brian.

Bug#1001543: cups-daemon: no printing at all because of ghostscript unrecoverable error

[Brian Potkin]

tags 1001543 moreinfo
thanks



Thank you for your report, Eric.

On Sat 11 Dec 2021 at 23:55:16 +0100, Eric Van Buggenhaut wrote:

> Package: cups-daemon
> Version: 2.3.3op2-7

Debian 11.1 did not ship with this version of cups-daemon.

> Severity: important
> X-Debbugs-Cc: ericv...@gmail.com
> 
> I installed cups on a fresh install and trying to print on a HP Laserjet 107r.
> 
> Any attempt at printing be it a test page or a document terminates with a
> 
> GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
> 
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Printer found with device ID: 
> MFG:HP;CMD:SPL,URF,FWV,PIC,EXT,PWGRaster;PRN:5UE14A;MDL:HP Laser 103 107 
> 108;CLS:PRINTER;CID:HPLJPCLMSMV1;MODE:SPL3,R000105;STATUS:BUSY; Device URI: 
> usb://HP/Laser%20103%20107%20108?serial=CNB2N2RJGL
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Device protocol: 2
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Sending data to printer.
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Sent 0 bytes...
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Start rendering...
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Processing page 1...
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Error: /ioerror in --showpage--
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Operand stack:
> D [11/Dec/2021:23:47:22 +0100] [Job 14] (/tmp/gs_INP1mG)   --nostringval--   
> 1   true
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Execution stack:
> D [11/Dec/2021:23:47:22 +0100] [Job 14] %interp_exit   .runexec2   
> --nostringval--   showpage   --nostringval--   2   %stopped_push   
> --nostringval--   showpage   showpage   false   1   %stopped_push   1990   1  
>  3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop 
>   showpage   1978   3   3   %oparray_pop   showpage   showpage   2   1   1   
> showpage   %for_pos_int_continue   1981   3   7   %oparray_pop   showpage   
> showpage   1840   2   9   %oparray_pop   showpage   showpage
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Dictionary stack:
> D [11/Dec/2021:23:47:22 +0100] [Job 14] --dict:772/1123(ro)(G)--   
> --dict:1/20(G)--   --dict:81/200(L)--   --dict:81/200(L)--   
> --dict:134/256(ro)(G)--   --dict:324/325(ro)(G)--   --dict:35/64(L)--   
> --dict:6/9(L)--   --dict:7/20(L)--
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Current allocation mode is local
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Last OS error: Broken pipe
> D [11/Dec/2021:23:47:22 +0100] [Job 14] GPL Ghostscript 9.55.0: Unrecoverable 
> error, exit code 1
> D [11/Dec/2021:23:47:22 +0100] [Job 14] Rendering completed
> 
> 
> 
> -- System Information:
> Debian Release: 11.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages cups-daemon depends on:
> ii  adduser  3.118
> ii  bc   1.07.1-2+b2
> ii  init-system-helpers  1.60
> ii  libavahi-client3 0.8-5
> ii  libavahi-common3 0.8-5
> ii  libc62.31-13+deb11u2
> ii  libcups2 2.3.3op2-7
> ii  libdbus-1-3  1.12.20-2
> ii  libgssapi-krb5-2 1.18.3-6+deb11u1
> ii  libpam0g 1.4.0-9+deb11u1
> ii  libpaper11.1.28+b1
> ii  libsystemd0  247.3-6
> ii  lsb-base 11.1.0
> ii  procps   2:3.3.17-5
> ii  ssl-cert 1.1.0+nmu1
> 
> Versions of packages cups-daemon recommends:
> ii  avahi-daemon  0.8-5
> ii  colord1.4.5-3
> pn  cups-browsed  
> pn  ipp-usb   

You have Recommends disabled?
 
> Versions of packages cups-daemon suggests:
> ii  cups   2.3.3op2-7
> ii  cups-bsd   2.3.3op2-7
> ii  cups-client2.3.3op2-7
> ii  cups-common2.3.3op2-7
> ii  cups-filters   1.28.7-1
> ii  cups-ppdc  2.3.3op2-3+deb11u1
> ii  cups-server-common 2.3.3op2-7
> pn  foomatic-db-compressed-ppds | foomatic-db  
> ii  ghostscript9.55.0~dfsg-3

Debian 11.1 did not ship with this version of ghostscript.

> ii  poppler-utils  20.09.0-3.1
> ii  printer-driver-cups-pdf [cups-pdf] 3.0.1-9
> pn  smbclient  
> ii  udev   247.3-6

You do not have a consistent Debian 11.1 system. Plus, my preference
is to debug on unstable. Anyway, has there been any improvement in
the printing situation in the meantine?

Regards,

Brian.

Bug#846381: avahi-daemon: cups frequently forgets about all printers untils restarting avahi-daemon

[Brian Potkin]

affects 846381 - cuos-daemon
thanks


On Tue 02 Jan 2018 at 17:51:06 +, Brian Potkin wrote:

[...]

> My interest in this bug arises from its affecting cups-daemon and my
> knowledge of avahi is not great. It seems avahi-daemon stops providing
> cups-browsed with information and the printer list would disappear, of
> course. I would have been interesting to find out if the same thing
> happens with the GTK dialog.

I am using cups 2.4.2-1+b1 on unstable with a default avahi-daemon.conf
and do not observe what you describe in your first post. cups always
sees the printers with 'lpstat -l -e'.

Cheers,

Brian.

Bug#1008053: cups-client: lpoptions as root doesn't update /etc/cups/lpoptions

[Brian Potkin]

forwarded 1008053 https://github.com/OpenPrinting/cups/issues/454
thanks



On Mon 21 Mar 2022 at 17:04:52 +0200, Yair Yarom wrote:

> Package: cups-client
> Version: 2.3.3op2-3+deb11u1huji
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> Running lpoptions as root (e.g. "lpoptions -d mafil") should update
> /etc/cups/lpoptions to be the defaults for all users (at least it was in the
> past and still claim to do so in the manual). But instead it tries to update
> /root/.cups/lpoptions.
> 
> Attached is a patch to fix it (to actually check the uid instead of home).

Thank you for your report, Yair. I observe the same as you do on cups
2.4.2-1+b1, so have forwarded the bug upstream.

Regards,

Brian.

Bug#998004: /usr/sbin/lpinfo: lpinfo: -U does not work despite saying so in the help

[Brian Potkin]

forwarded 998004 https://github.com/OpenPrinting/cups/issues/453
thanks


On Thu 28 Oct 2021 at 14:51:42 +0200, Roland Hieber wrote:

> Package: cups-client
> Version: 2.3.3op2-3+deb11u1
> Severity: normal
> File: /usr/sbin/lpinfo
> 
> Dear Maintainer,
> 
> I tried using lpinfo with a hostname and a user name, but it complains:
> 
> $ lpinfo -h gutenberg.mydomain -U myuser -l -v
> lpinfo: Unknown option "U".
> Usage: lpinfo [options] -m
>  lpinfo [options] -v
> Options:
> -E  Encrypt the connection to the server
> -h server[:port]Connect to the named server and port
> -l  Show verbose (long) output
> -m  Show models
> -U username Specify the username to use for authentication
> -v  Show devices
> --device-id device-id   Show models matching the given IEEE 1284 device ID
> --exclude-schemes scheme-list
>   Exclude the specified URI schemes
> --include-schemes scheme-list
>   Include only the specified URI schemes
> --language locale   Show models matching the given locale
> --make-and-model name   Show models matching the given make and model name
> --product name  Show models matching the given PostScript product
> --timeout seconds   Specify the maximum number of seconds to discover 
> devices
> 
> These two lines in the help seem to be conflicting:
> 
>   lpinfo: Unknown option "U".
> [...]
>   -U username Specify the username to use for authentication
> 
> It does not matter where on the command line I put the -U, the outcome is
> always the same, and I haven't figured out yet how to authenticate to
> the server with a different user name.

Thank you for your report, Roland.

The output from your command is correct behaviour; see the manual.
The Usage output is not correct. I have sent a report to upstream.

Regards,

Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

tags 1013437 - unreproducible
thanks



On Sun 03 Jul 2022 at 06:00:28 +0100, Gareth Evans wrote:

> On Sat  2 Jul 2022, at 23:43, Brian Potkin  wrote:
> [...]
> > On Fri 01 Jul 2022 at 13:37:07 +0100, Gareth Evans wrote:
> >> Driverless queues don't seem to work
> >> no matter how set up.
> >
> > Yet earlier (and at OpenPrinting) you said:
> >
> >   Having deleted all printers from system-config-printer,
> >   $ sudo lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m 
> > driverless:ipp://192.168.0.14/ipp/print
> >   now succeeds, and so does printing to it.
> 
> Apologies, driverless queues only work if set up by lpadmin.
> Everywhere queues work from cups-web.

OK. That's clear enough.
> 
> May I suggest you may not be able to reproduce the bug as you (said
> you) don't have a fax-capable printer? 

Indeed you may. It had slipped my mind but it was the reason I thought
upstream was a reasonable place to go.

> It seems to me that my driverless print jobs end up in a fax queue if
> the queue is created by cups-web or s-c-p.  If this is the main
> symptom, I would be grateful if you would advise if this changes what
> the bug should be reported against.

The PPD generated by everywhere suits queues set up by lpadmin and the
CUPS web interface. One of the queues set up with cups-filters,
driverless doesn't work. I'd stick with cups-filters for the time being.

> I respect that you may no longer wish to be involved with this issue -
> thanks for your help - here is some further info for info's sake :)
> 
> At least one other user seems to have a similar problem:
> 
> "However, printing does not work, although the printer gets data, but
> then hangs."
> https://lists.debian.org/debian-user/2022/06/msg00558.html
> 
> The printer concerned there also appears to have airprint/fax
> https://productz.com/en/samsung-xpress-sl-c480fw/p/wxnG7
> 
> Substituting "gives up" for "hangs", this reflects my issue too.
> 
> I can find no significant difference between driverless PPDs, though
> everywhere PPDs do not include fax details, and everywhere queues
> added from cups-web succeed in printing.  Might this be another
> pointer to the issue?

You are making a good case.
> 
> $ history | grep testq-drvless
> sudo lpadmin -p testq-drvless -v ipp://192.168.0.14/ipp/print -E -m 
> driverless:ipp://192.168.0.14/ipp/print
> 
> $  sudo cat testq-drvless.ppd | grep -i fax
> *NickName: "Brother MFC-L2740DW series, Fax, driverless, cups-filters 1.28.7"
> *cupsIPPFaxOut: True
> *OpenUI *faxPrefix/Pre-Dial Number: PickOne
> *OrderDependency: 10 AnySetup *faxPrefix
> *DefaultfaxPrefix: None
> *faxPrefix None: ""
> *CloseUI: *faxPrefix
> *CustomfaxPrefix True: ""
> *ParamCustomfaxPrefix Text: 1 string 0 64
> 
> $ history | grep ippeve
> sudo lpadmin -p testq-ippeve -v ipp://192.168.0.14/ipp/print -E -m everywhere
> 
> $ sudo cat testq-ippeve.ppd | grep -i fax
> $ 
> 
> 
> Though even testq-drvless sometimes shows strange job attribs in s-c-p: 
> 
> "job-printer-state-message: Phone number for fax not valid! Fax cannot be 
> sent"
> "job-printer-uri: ipp://localhost/printers/testq-drvless"
> 
> though the job (from geany) actually printed.  
> 
> 
> $ sudo diff CUPSWEBDL.ppd testq-drvless.ppd
> 20c20
> < *APSupplies: "http://mfcl2740dw.local./net/net/airprint.html;
> ---
> > *APSupplies: "http://192.168.0.14/net/net/airprint.html;
> 
> $ sudo diff CUPSWEBDL.ppd SCPDL.ppd
> $
> 
> $ ping mfcl2740dw.local
> PING mfcl2740dw.local (192.168.0.14) 56(84) bytes of data.
> 64 bytes from 192.168.0.14 (192.168.0.14): icmp_seq=1 ttl=255 time=9.80 ms
> 
> $ ping mfcl2740dw.local.
> PING mfcl2740dw.local. (192.168.0.14) 56(84) bytes of data.
> 64 bytes from 192.168.0.14 (192.168.0.14): icmp_seq=1 ttl=255 time=3.62 ms
> 
> $ sudo lpadmin -p testqhostname -v ipp://mfcl2740dw.local/ipp/print -E -m 
> driverless:ipp://mfcl2740dw.local/ipp/print 
> lpadmin: Printer drivers are deprecated and will stop working in a future 
> version of CUPS.
> 
> $ sudo diff testqhostname.ppd CUPSWEBDL.ppd
> $ 
> 
> 
> $ lp -d testqhostname /etc/nsswitch.conf
> request id is testqhostname-56 (1 file(s))
> 
> Succeeds.

Good.

> /var/log/cups/error_log
> [...]
> 2833 D [03/Jul/2022:02:05:45 +0100] Create-Job 
> ipp://localhost/printers/testqhostname
> [...]
> 3359 D [03/Jul/2022:02:05:46 +0100] [Client 605] Processing GET 
> /printers/testqhostname.ppd
> 3360 D [03/Jul/2022:02:05:46 +0100] [Client 605] 
> filename="/etc/cups/ppd/testqhostname.ppd", type=application/vnd.cups-ppd
> [...]
> 3794 

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

tags 1013437 unreproducible
thanks




On Fri 01 Jul 2022 at 13:37:07 +0100, Gareth Evans wrote:

> On Fri  1 Jul 2022, at 12:54, Brian Potkin  wrote:
> [...]
> > Unexpected and not understandable. There is enough going on in this
> > issue not to want to take it further. Your MFC-L2740DW understands
> > Apple raster (image/urf):
> >
> >   pdl=application/octet-stream,image/urf,image/pwg-rastei
> >
> > and /etc/nsswitch.conf should print.
> >
> 
> > Anyway, you report that everywhere and driverless queues work. 
> 
> Everywhere queues work if added via lpadmin or (I have just
> discovered) cups web interface.

Fine. It seems there aren't any CUPS or cups-filters bugs there.

>  Driverless queues don't seem to work
> no matter how set up.

Yet earlier (and at OpenPrinting) you said:

  Having deleted all printers from system-config-printer,
  $ sudo lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m 
driverless:ipp://192.168.0.14/ipp/print
  now succeeds, and so does printing to it.

> System-config-printer lists the printer twice under 
> 
> Add Printer > "Network Printer" 
> 
> one listing per connection - "IPP network printer via DNS-SD" or
> "Driverless IPP" - neither of which print.

The first will not (in general) print without a Brother vendor driver
on the system. The second works for me. I think you see my problem
in being unable to reproduce your observation. Apart from the printer
model, our bullseye printing systems are (or should be) identical.

> I am grateful for your help and quite understand the reluctance to
> continue with a situation that doesn't make sense.

It is the inability to reproduce your experience that makes me leery
of seeing any bug in the printing system.
 
> However, given that 
> 
> - airprint works from iphone

The iphone will be sending Apple raster directly to the printer. It is
obliged to by Apple's AirPrint specication. CUPS is not involved. It
prints, whereas your dierct sending of Apple raster, for whatever reson,
did not.

> - driverless IPP works from cups 2.4 on Ubuntu 22.04

It works for me on Debian 11.3.

>  - I get the same behaviour from an identical printer on a
> different network with the same Debian 11.3 system, and the original
> printer with a different Debian 11.0 system
> 
> there does seem to be a Debian-related bug somewhere.
> 
> Is there anyone else you would suggest referring this to, or any other
> package to consider filing against?
`> 
> What chance is there of Debian updating cups in stable?  Is there a
> way to request consideration of this?
> 
> Meanwhile, is using the cups 2.4 testing packages in stable unwise?
> Or a known-working Buster version?
> 
> I can manage well enough with everywhere printing, but the users I
> support (if I upgrade them to Bullseye) will not appreciate the cups
> web interface or lpadmin, s-c-p is preferred.

I do not feel competent to triage this issue any further. s-c-p is not
even uder the printin system umbrella.

Cheers,

Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Thu 30 Jun 2022 at 23:18:42 +0100, Gareth Evans wrote:

> On Thu 30 Jun 2022, at 14:57, Brian Potkin  wrote:

[...]

> > 5. Send both files directly to the printer with
> >netcat 192.168.0.14 9100 < ippeve.urf
> 
> Command seemed to hang or await job completion.  
> 
> Printer printed a good 30-odd pages, either blank or containing a line
> or two of binary/gibberish.
> 
> Device job cancel button did not respond.  Opened paper tray, pressed
> cancel button, job stopped.  Re-inserted tray, job continued.  Opened
> tray, cancelled job, ^C to stop netcat, power cycled printer, order
> restored.
> 
> >netcat 192.168.0.14 9100 < drvless.urf
> 
> Same, though this time I stopped it after a few pages

Unexpected and not understandable. There is enough going on in this
issue not to want to take it further. Your MFC-L2740DW understands
Apple raster (image/urf):

  pdl=application/octet-stream,image/urf,image/pwg-rastei

and /etc/nsswitch.conf should print.

Anyway, you report that everywhere and driverless queues work. Also,
the error_logs show all filters completing successfully and cupsfilter
produces valid output. There do not appear to be any bugs in cups or
cups-filters.

I would suggest closing #472 at OpenPrinting.

Cheers,

Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Thu 30 Jun 2022 at 01:03:27 +0100, Gareth Evans wrote:

> Does that mean cups-filters is not the appropriate package to file
> against?  If so, do you have any suggestions as to which might be?

It indicates the everywhere and driverless models are behaving as
expected. Let's continue this line of inquiry:

1. Set up queues
   lpadmin -p testq-ippeve -v ipp://192.168.0.14/ipp/print -E -m everywhere
   lpadmin -p testq-drvless -v ipp://192.168.0.14/ipp/print -E -m 
driverless:ipp://192.168.0.14/ipp/print   

2. As root, do
   cupsfilter -p /etc/cups/ppd/testq-ippeve.ppd -m printer/foo -e 
/etc/nsswitch.conf > ippeve.urf
   cupsfilter -p /etc/cups/ppd/testq-drvless.ppd -m printer/foo -e 
/etc/nsswitch.conf > drvless.urf
 
3. Open ippeve.urf and drvless.urf with less and check for UNIRAST at
   the top left corner. Give the file sizes. View the files with
   rasterview.

4. Check the printer has an open port 9100.

5. Send both files directly to the printer with
   netcat 192.168.0.14 9100 < ippeve.urf
   netcat 192.168.0.14 9100 < drvless.urf

Cheers,

Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Tue 28 Jun 2022 at 11:47:57 +0100, Gareth Evans wrote:

> OK thanks for your help.  I have updated the upstream report and will
> update here when further info is available.

For printing your log shows:

D [28/Jun/2022:02:55:42 +0100] [Job 42] 6 filters for job:  

D [28/Jun/2022:02:55:42 +0100] [Job 42] bannertopdf 
(application/vnd.cups-pdf-banner to application/pdf, cost 32)   
D [28/Jun/2022:02:55:42 +0100] [Job 42] pdftopdf (application/pdf to 
application/vnd.cups-pdf, cost 66) 
D [28/Jun/2022:02:55:42 +0100] [Job 42] gstoraster (application/vnd.cups-pdf to 
application/vnd.cups-raster, cost 99
)   

D [28/Jun/2022:02:55:42 +0100] [Job 42] rastertopwg 
(application/vnd.cups-raster to image/urf, cost 100)
D [28/Jun/2022:02:55:42 +0100] [Job 42] - (image/urf to 
printer/cupsweb3/image/urf, cost 0) 
D [28/Jun/2022:02:55:42 +0100] [Job 42] - (printer/cupsweb3/image/urf to 
printer/cupsweb3, cost 0)

Searching for "exited with no errors" shows they all the filters
completed successfully. The everywhere model uses the same filter chain.

Cheers,

Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Tue 28 Jun 2022 at 11:03:14 +0100, Brian Potkin wrote:

> I am not certain, but it probably is. Please send the log to the
> upstream bug report. I think a .txt suffix will have to be added
> for it to be accepred.

Forgot to mention: I do not have a fax-enabled device to test further.

-- 
Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Tue 28 Jun 2022 at 03:07:52 +0100, Gareth Evans wrote:

> And FWIW, attached is an end-of-log extract of creating a driverless IPP 
> printer ("cupsweb3") from cups web interface, then printing a test page.  
> Again, s-c-p reports job completed, but nothing printed.
> 
> There are continued references to "ipp/faxout" - and no references to 
> ipp/print.
> 
> Eg:
> 
> line
> 2584 D [28/Jun/2022:02:55:42 +0100] [Job 42] Calling 
> FindDeviceById(cups-cupsweb3)
> 2585 D [28/Jun/2022:02:55:42 +0100] [Job 42] Resolved as 
> \"ipp://mfcl2740dw.local:631/ipp/faxout\"...
> 
> Might this be relevant?

I am not certain, but it probably is. Please send the log to the
upstream bug report. I think a .txt suffix will have to be added
for it to be accepred.

Cheers,

Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Mon 27 Jun 2022 at 19:31:11 +0100, Brian Potkin wrote:

>   >/var/lod/error_log

/var/log/error_log, of course.

-- 
Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Mon 27 Jun 2022 at 18:43:16 +0100, Gareth Evans wrote:

> On Mon 27 Jun 2022, at 18:41, Till Kamppeter  wrote:
> [...]
> > Seems that it is able to access the printer for sending a job to it 
> > (done as user "lp"?) but not to poll the printer's capabilities via IPP 
> > (when running the "lpadmin" command).
> 
> The printer/queue was not created, so I didn't get as far as testing printing.
> 
> Which is to say that testqq didn't appear in system-config-printer.

ipp://192.168.0.14/ipp/print is the most fundamental URI available.
Assuming the IP address is unchanged, do (as root)

  cupsctl --debug-logging
  >/var/lod/error_log

Set up a driverless queue as before. Compress error_log with gz or xz
and send it here.

Cheers,

Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Mon 27 Jun 2022 at 17:22:22 +0100, Gareth Evans wrote:

> On Mon 27 Jun 2022, at 17:11, Till Kamppeter  wrote:
> > And are you able to print now?
> >
> > Till
> >
> 
> Only to the queue added via lpadmin ... everywhere
> 
> No autodetected printers appear in system-config-printer or application print 
> dialogs.
> 
> $ sudo lpadmin -p testq -v 
> "ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local" -E -m 
> driverless:"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local"
> [sudo] password for user: 
> lpadmin: Printer drivers are deprecated and will stop working in a future 
> version of CUPS.
> 
> $ lp -d testq /etc/nsswitch.conf
> request id is testq-12 (1 file(s))
> 
> Nothing prints over 5GHz, nor 2.5GHz wifi connections.
> 
> Same behaviour as before in both cases - printer lights up but nothing prints.

The problem I have here is in understanding. A queue set up with the
cups-filters driverless for -m is based strongly on CUPS everywhere.

Here is a URI for the device. It is equivalent to what you already
have:

  ipp://192.168.0.14/ipp/print

Set up

  lpadmin -p testeveq -v ipp://192.168.0.14/ipp/print -E -m everywhere

and print to testeveq as before. We expect this to work.

Now

  lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m 
driverless:ipp://192.168.0.14/ipp/print

and print to testq. How does that go?

Cheers,

Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Fri 24 Jun 2022 at 22:23:06 +0100, Gareth Evans wrote:

> On Fri 24 Jun 2022, at 18:55, Brian Potkin  wrote:

[...]

> > Print:
> >
> >  lp -d testq /etc/nsswitch.conf
> >
> > The result?
> 
> $ lp -d testq /etc/nsswitch.conf
> request id is testq-8 (1 file(s))
> 
> Printer lights up and looks like business, but nothing prints.
> 
> Job shows as "completed" in system-config-printer queue monitor, job 
> attributes include
> 
> job-state-reasons: processing-to-stop-print

I was a little remiss in not pursuing this further before going
upstrean. Please give

  avahi-browse -rt _ipp._tcp
  avahi-browse -rt _uscan._tcp

avahi-browse is in the avahi-utils package.

Cheers,

Brian.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

tags 1013437 moreinfo
thanks



On Thu 23 Jun 2022 at 17:00:31 +0100, Gareth Evans wrote:

> Package: cups
> Version: 2.3.3op2-3+deb11u2
> Severity: normal
> X-Debbugs-Cc: donots...@fastmail.fm
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> Attempting to print to driverless printer queue for airprint printer.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Brother MFC-L2740DW with print/fax/scan/copy abilities has stopped printing
> from queues not added with lpadmin.
> 
> Autodetected queues, as well as those added via cups web interface or system-
> config-printer, do not produce output.
> 
> This worked until recently, though I don't print often so don't know when it
> changed.
> 
> Printing only works if a queue is added by using the lpadmin command:
> 
> $ sudo lpadmin -p MFC-L2740DW -v
> ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/ -E -m everywhere
> 
> Autodetected printer queues are not created if a maually-added printer is
> already set up.
> 
>* What was the outcome of this action?
> 
> No physical output from printer.

Thank you for your report, Gareth.

Set up

 lpadmin -p testq -v "ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/" -E 
-m driverless:"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local/"

Print:

 lp -d testq /etc/nsswitch.conf

The result?

Regards,

Brian.

Bug#1012844: wpasupplicant: please provide a default wpa_supplicant.conf file to have /run/wpa_supplicant in the netdev group

[Brian Potkin]

On Thu 16 Jun 2022 at 15:56:29 +0100, Brian Potkin wrote:

> On Wed 15 Jun 2022 at 14:52:05 +0200, Andrej Shadura wrote:
> 
> > Hi,
> > 
> > On Wed, 15 Jun 2022, at 13:55, Vincent Lefevre wrote:
> > > Package: wpasupplicant
> > > Version: 2:2.10-9+b1
> > > Severity: wishlist
> > >
> > > Users should not have to modify the default configuration to make
> > > things work as expected. Currently, it is not possible to run wpa_cli
> > > and wpa_gui as a normal user from the netdev group, contrary to other
> > > wifi-related tools like iwconfig, nmcli, iw, and in the past, wicd.
> > 
> > Thanks for the bug report!
> 
> Thanks for the rapid response, Andrej.
>  
> > Would something like this work for you?
> > https://salsa.debian.org/debian/wpa/-/commit/14709d27604a4dc34cf07e9ef5ccb579cf9d7192
> > 
> > Unfortunately, I’m not sure there is a better way to provide a default
> > without patching wpa_supplicant’s config parser.
> 
> I put the four lines you provided into bullseye's service file. wpa_cli   
> 
> and wpa_gui can now be run by a non-root user in the netdev group when
> /en/i has a simple (non-roaming) stanza. This is a win.

I forgot to mention that I had to use

  ExecStart=/sbin/wpa_supplicant

for the service to function.

Cheers,

Brian.

Bug#1012844: wpasupplicant: please provide a default wpa_supplicant.conf file to have /run/wpa_supplicant in the netdev group

[Brian Potkin]

On Wed 15 Jun 2022 at 14:52:05 +0200, Andrej Shadura wrote:

> Hi,
> 
> On Wed, 15 Jun 2022, at 13:55, Vincent Lefevre wrote:
> > Package: wpasupplicant
> > Version: 2:2.10-9+b1
> > Severity: wishlist
> >
> > Users should not have to modify the default configuration to make
> > things work as expected. Currently, it is not possible to run wpa_cli
> > and wpa_gui as a normal user from the netdev group, contrary to other
> > wifi-related tools like iwconfig, nmcli, iw, and in the past, wicd.
> 
> Thanks for the bug report!

Thanks for the rapid response, Andrej.
 
> Would something like this work for you?
> https://salsa.debian.org/debian/wpa/-/commit/14709d27604a4dc34cf07e9ef5ccb579cf9d7192
> 
> Unfortunately, I’m not sure there is a better way to provide a default
> without patching wpa_supplicant’s config parser.

I put the four lines you provided into bullseye's service file. wpa_cli 
  
and wpa_gui can now be run by a non-root user in the netdev group when
/en/i has a simple (non-roaming) stanza. This is a win.

With wpa-roam and the manual directive in /e/n/i the conf file still
requires "ctrl_interface=DIR=/run/wpa_supplicant GROUP=netdev". However,
such users should know what they are doing and aiming for.

I wonder whether the change to the service file should have a mention
in NEWS.Debian.

Regards,

Brian.

Bug#1012174: Inconsistent advice wrt security archive

[Brian Potkin]

On Tue 31 May 2022 at 14:58:00 +0200, Julien Cristau wrote:

> On Tue, May 31, 2022 at 02:26:39PM +0200, David Prévot wrote:
> > Package: www.debian.org,release-notes
> > Severity: normal
> > X-Debbugs-Cc: t...@security.debian.org
> > 
> > Hi teams,
> > 
> > The [errata] advises one to use 
> > 
> >   deb http://security.debian.org/debian-security bullseye-security main 
> > contrib non-free
> > 
> > while the [release-notes] advises
> > 
> >   deb https://deb.debian.org/debian-security bullseye-security main contrib
> > 
> > Even if both will have the same result (the last time a non-free package
> > was uploaded to the security archive may have been during Etch), having
> > two different official advice makes it difficult in some situation
> > (“what should we actually use?”). Is the use of HTTPS via deb.d.o
> > preferable over HTTP via security.d.o? If so maybe the errata should be
> > updated, if it’s the other way around, the realease-notes should be
> > updated.
> > 
> >   errata: https://www.debian.org/releases/stable/errata#security
> >   release-notes: 
> > https://www.debian.org/releases/stable/amd64/release-notes/ch-information#security-archive
> > 
> The release-notes version is preferred, as far as scheme and hostname.

There appears to be a consensus in favour of https. For example:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692#37

Regards,

Brian.

Bug#1008997: [OpenPrinting/ipp-usb] ipp-usb is not ready for this device (Issue #48)

[Brian Potkin]

On Thu 28 Apr 2022 at 10:18:24 +0200, alain wrote:

Alain,

Take a look at github. The mail below does not appear to have made it
through to there. I suggest you put it directly into github.

Cheers, 

Brian.

> hello alexander pevzner .
> 
> I will try to answer your 4 questions clearly:
> 
> 1) combinations that work :
> - stable kernel with stable ipp-usb
> - kernel testing / sid with ipp-usb stable version
> 
> 
> 2) combinations that definitely don't work:
> - kernel testing / sid with ipp-usb (testing / sid version)
> 
> once my printer is plugged , system-config-printer do not recognize it .
> 
> i can not print even a test page . and never see the printer icon .
> 
> 
> 3) when it works, it works constantly.
> system-config-printer is constantly fully functional.
> 
> once i plug in my printer (or power it on) , after a very short delay ,
> 
> system-config-printer recognize it and i can print a test page and my
> documents .
> 
> i see the printer icon  and it is fully functional .
> 
> 
> 4) when it doesn't work, it's definitive. it doesn't work.
> 
> system-config-printer never recognize it and i can not print even a test
> page
> 
> apparmor seems to do nothing with the testing/sid  version of ipp-usb .
> 
> 
> I answered your questions as you wanted?
> Did it help you ?
> 
> friendly,
> respectfully,
> 
> alain.
> 
> 
> nb: for instance , i am working with the stable version of ipp-usb and all
> is nearly perfect .
> 
> under 5.17 kernel . my system is constantly up-to-date (sid) .
> 
> 
> in case of , sorry for the flood .
> 
> 
> Le 28/04/2022 à 09:58, alain a écrit :
> > 
> > re ,
> > 
> > up .
> > 
> > 
> > Le 27/04/2022 à 13:02, alain a écrit :
> > > 
> > > hello alexander pevzner .
> > > 
> > > I will try to answer your 4 questions clearly:
> > > 
> > > 1) combinations that work :
> > > - stable core with stable ipp-usb
> > > - kernel testing / sid with ipp-usb stable
> > > 
> > > 2) combinations that definitely don't work:
> > > - kernel testing / sid with ipp-usb (testing / sid version)
> > > 
> > > 3) when it works, it works constantly.
> > > system-config-printer is constantly fully functional.
> > > 
> > > 4) when it doesn't work, it's definitive. it doesn't work.
> > > 
> > > I answered your questions as you wanted?
> > > Did it help you ?
> > > 
> > > friendly,
> > > respectfully,
> > > alain.
> > > 
> > > 
> > > 
> > > Translated with www.DeepL.com/Translator (free version)
> > > 
> > > Le 27/04/2022 à 11:45, Alexander Pevzner a écrit :
> > > > 
> > > >  1. Is there any configuration (combination of kernel version and
> > > > ipp-usb version), that *definitely works*?
> > > >  2. Is there any configuration, that *definitely doesn't work*?
> > > >  3. When it works, does it work reliable or time to time?
> > > >  4. When it doesn't work, doesn't it work always or time to time?
> > > > 

Bug#1008997: cups: impossible to print on hp envy 5536 from sid

[Brian Potkin]

On Fri 08 Apr 2022 at 18:23:42 +0100, Brian Potkin wrote:

> On Thu 07 Apr 2022 at 20:36:45 +0200, alain wrote:
> 
> > i've just gone to this thread :
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983349
> > 
> > i saw interesting things but , apparently , nothing that applies to my
> > actual case .
> > 
> > alain@sid:~$ sudo systemctl list-units "ipp-usb*" | grep service
> > [sudo] Mot de passe de alain :
> >   ipp-usb.service loaded active running Daemon for IPP over USB printer
> > support
> > 
> > 
> > alain@sid:~$ scanimage -L
> > device `hpaio:/usb/ENVY_5530_series?serial=CN595530XD06BX' is a
> > Hewlett-Packard ENVY_5530_series all-in-one
> 
> Your scanner is not found. Also, ippfind (which is used by driverless)
> and avahi-browse find the bbox but not the ENVY.

With the unstable version of ipp-usb, please do this:

1. Disconnect the device from USB.

2. The logs for ipp-usb are in /var/log/ipp-usb/. We want the first one,
   named like SOMETHING.log.

3. As root, empty SOMETHING.log with

 >/var/log/ipp-usb/SOMETHING.log

4. Resconnect the device to USB.

5. Copy SOMETHING.log to somewhere as connect.txt and compress it with

 gzip connect.txt

6. Send connect.txt.gz here.

Cheers,

Brian.

Bug#952704: libqt5printsupport5: Printer and queue attributes not available

[Brian Potkin]

tags 952704 upstream
found 952704 5.15.2+dfsg-16
thanks


In my opinion, the Qt print dialog should support the CUPS temporary
queue facility correctly. CUPS has APIs to do this. There shoudn't be
any need to set up a permanent manual queue or have cups-browsed add
a permanent queue in order to get remote queue or printer attributes 

Cheers,

Brian.

Bug#1008997: cups: impossible to print on hp envy 5536 from sid

[Brian Potkin]

On Thu 07 Apr 2022 at 20:36:45 +0200, alain wrote:

> i've just gone to this thread :
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983349
> 
> i saw interesting things but , apparently , nothing that applies to my
> actual case .
> 
> alain@sid:~$ sudo systemctl list-units "ipp-usb*" | grep service
> [sudo] Mot de passe de alain :
>   ipp-usb.service loaded active running Daemon for IPP over USB printer
> support
> 
> 
> alain@sid:~$ scanimage -L
> device `hpaio:/usb/ENVY_5530_series?serial=CN595530XD06BX' is a
> Hewlett-Packard ENVY_5530_series all-in-one

Your scanner is not found. Also, ippfind (which is used by driverless)
and avahi-browse find the bbox but not the ENVY.

In another mail you ask about ipp-usb=0.9.17-3+b4. I think that version
is installable on unstable. You could try with 'dpkg -i...'.

Cheers,

Brian. 

Bug#1008997: cups: impossible to print on hp envy 5536 from sid

[Brian Potkin]

On Thu 07 Apr 2022 at 20:36:45 +0200, alain wrote:

> i've just gone to this thread :
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983349
> 
> i saw interesting things but , apparently , nothing that applies to my
> actual case .
> 
> alain@sid:~$ sudo systemctl list-units "ipp-usb*" | grep service
> [sudo] Mot de passe de alain :
>   ipp-usb.service loaded active running Daemon for IPP over USB printer
> support
> 
> 
> alain@sid:~$ scanimage -L
> device `hpaio:/usb/ENVY_5530_series?serial=CN595530XD06BX' is a
> Hewlett-Packard ENVY_5530_series all-in-one
> 
> 
> alain@sid:~$ apt policy sane-airscan hplip cups system-config-printer
> ipp-usb
> sane-airscan:
>   Installé : 0.99.27-1
>   Candidat : 0.99.27-1
>  Table de version :
>  *** 0.99.27-1 500
>     100 http://deb.debian.org/debian testing/main amd64 Packages
>     500 http://deb.debian.org/debian unstable/main amd64 Packages
>     100 /var/lib/dpkg/status
>  0.99.24-1 100
>     100 http://deb.debian.org/debian stable/main amd64 Packages
> hplip:
>   Installé : (aucun)
>   Candidat : 3.22.2+dfsg0-1
>  Table de version :
>  3.22.2+dfsg0-1 500
>     500 http://deb.debian.org/debian unstable/main amd64 Packages
>     100 /var/lib/dpkg/status
>  3.21.12+dfsg0-1 100
>     100 http://deb.debian.org/debian testing/main amd64 Packages
>  3.21.2+dfsg1-2 100
>     100 http://deb.debian.org/debian stable/main amd64 Packages
> cups:
>   Installé : 2.4.1op1-2
>   Candidat : 2.4.1op1-2
>  Table de version :
>  *** 2.4.1op1-2 500
>     100 http://deb.debian.org/debian testing/main amd64 Packages
>     500 http://deb.debian.org/debian unstable/main amd64 Packages
>     100 /var/lib/dpkg/status
>  2.3.3op2-3+deb11u1 100
>     100 http://deb.debian.org/debian stable/main amd64 Packages
> system-config-printer:
>   Installé : 1.5.16-1
>   Candidat : 1.5.16-1
>  Table de version :
>  *** 1.5.16-1 500
>     100 http://deb.debian.org/debian testing/main amd64 Packages
>     100 http://deb.debian.org/debian testing/main i386 Packages
>     500 http://deb.debian.org/debian unstable/main amd64 Packages
>     500 http://deb.debian.org/debian unstable/main i386 Packages
>     100 /var/lib/dpkg/status
>  1.5.14-1 100
>     100 http://deb.debian.org/debian stable/main amd64 Packages
>     100 http://deb.debian.org/debian stable/main i386 Packages
> ipp-usb:
>   Installé : 0.9.20-1
>   Candidat : 0.9.20-1
>  Table de version :
>  *** 0.9.20-1 500
>     100 http://deb.debian.org/debian testing/main amd64 Packages
>     500 http://deb.debian.org/debian unstable/main amd64 Packages
>     100 /var/lib/dpkg/status
>  0.9.17-3+b4 100
>     100 http://deb.debian.org/debian stable/main amd64 Packages
> 
> 
> alain@sid:~$ lsusb -v | grep -A 3 bInterfaceClass.*7
> Couldn't open device, some information will be missing
> Couldn't open device, some information will be missing
> Couldn't open device, some information will be missing
> Couldn't open device, some information will be missing
>   bInterfaceClass 7 Printer
>   bInterfaceSubClass  1 Printer
>   bInterfaceProtocol  4
>   iInterface  0
> --
>   bInterfaceClass 7 Printer
>   bInterfaceSubClass  1 Printer
>   bInterfaceProtocol  2 Bidirectional
>   iInterface  0
> --
>   bInterfaceClass 7 Printer
>   bInterfaceSubClass  1 Printer
>   bInterfaceProtocol  4
>   iInterface  0
> Couldn't open device, some information will be missing
> Couldn't open device, some information will be missing
> --
>   bInterfaceClass 7 Printer
>   bInterfaceSubClass  1 Printer
>   bInterfaceProtocol  4
>   iInterface  0
> Couldn't open device, some information will be missing
> Couldn't open device, some information will be missing
> Couldn't open device, some information will be missing
> Couldn't open device, some information will be missing
> Couldn't open device, some information will be missing
> 
> 
> firefox http://127.0.0.1:6
> 
> gives :
> 
> ipp-usb is not ready for this device

The ipp-usb service is active but neither 'driverless' nor ippfind
see the printer and sane-airscan does not appear to work. You also
cannot access the web interface. I am lost!

The message

  ipp-usb is not ready for this device

is coming from ipp-usb. It seems to me that this is the most important
information you have supplied.

I suggest you report this issue upsteam (give the error message).

  https://github.com/OpenPrinting/ipp-usb/issues

You will have to sign up to github.

> these commands can help you ?

They help me to guide you to expert help. But you have been very helpful

Cheers,

Brian

Bug#1008997: cups: impossible to print on hp envy 5536 from sid

[Brian Potkin]

On Thu 07 Apr 2022 at 09:23:25 +0200, alain wrote:

> 
> Le 06/04/2022 à 17:59, Brian Potkin a écrit :
> > On Wed 06 Apr 2022 at 16:49:30 +0200, alain wrote:
> > 
> > > Le 06/04/2022 à 16:06, Brian Potkin a écrit :
> > > > Is the ENVY*directly*  connected to a USB port on the computer?
> > > 
> > > yes it is directly connected via usb to the pc .
> > I thiught it is but was just checking.
> > > when the printer is connected , it does not print at all .
> > the ipp-usb daemon detects the printer and is activee. That is good.
> > The avahi-browse and driverless commands do not work for the printer
> > nd they should.
> > 
> > How do you go on with 'http://127.0.0.1:6' in a browser?
> 
> in system-config -printer , the thing you created (the icon "envy"  like
> your last command done it)
> 
> is well shown . but i can not print . even a test page .
> 
> the printer is not  automatically recognized (not the case in bullseye where
> it is very well recognized )
> 
> when i had the hplip installed , the icon "envy 5530 ..." was created but
> has never  gone to be functionnal .
> 
> is my printer too old ? do i have to change it ?

You provided information at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983349

that cleary shows your printer is new enough to support IPP-over-USB.
Why not repeat all the commands I gave there?

> i set printer on ,  it says :
> 
> ipp-usb is not ready for this device

Where does it say this?

Can you access the printer from a browser with http://127.0.0.1:6000'?
 
> > > also i can't  shut down the computer .
> > Just switch off ?
> 
> the printer never  switches off and the pc never , too .
> 
> or after a very very very long time and i didn't wait more than 1 ou 2
> minutes
> 
> (that's enough normally it is instantly )
> 
> to switch off the printer , i have to unplug it (mains and usb) , replug it
> (mains only) ,
> 
> set it off (there it is ok) and replug it (usb) .
> 
> and , only in this case , it is ok for the pc .
> 
> with bullseye stable , all is ok , i have no problem . retested this morning

This seems more a matter of your setup on unstable and unrelated to
printing.

Cheers,

Brian.

Bug#1008997: cups: impossible to print on hp envy 5536 from sid

[Brian Potkin]

On Wed 06 Apr 2022 at 16:49:30 +0200, alain wrote:

> 
> Le 06/04/2022 à 16:06, Brian Potkin a écrit :
> > Is the ENVY*directly*  connected to a USB port on the computer?
> 
> 
> yes it is directly connected via usb to the pc .
 
I thiught it is but was just checking.
 
> when the printer is connected , it does not print at all .

the ipp-usb daemon detects the printer and is activee. That is good.
The avahi-browse and driverless commands do not work for the printer
nd they should.

How do you go on with 'http://127.0.0.1:6' in a browser?
 
> also i can't  shut down the computer .

Just switch off?
 
> box bouygues (france)
> 
> Fast5330b-r1
> 
> serial : 124251137275525
> 
> firmware :20.8.6

Thank you. That clarifies that.

Cheers,

Brian.

Bug#1008997: cups: impossible to print on hp envy 5536 from sid

[Brian Potkin]

On Wed 06 Apr 2022 at 15:17:40 +0200, alain wrote:

> Package: cups
> Version: 2.4.1op1-2
> Followup-For: Bug #1008997
> X-Debbugs-Cc: compte.perso.de-al...@bbox.fr
> 
> alain@sid:~$ driverless
> 
> 
> alain@sid:~$ ippfind -T 10
> ipp://bbox.local:631/
> 
> 
> alain@sid:~$  avahi-browse -rt _ipp._tcp
> + enp4s0 IPv4 bbox Ippos Printer Internet Printer local
> = enp4s0 IPv4 bbox Ippos Printer Internet Printer local
>hostname = [bbox.local]
>address = [192.168.1.254]
>port = [631]
>txt = []
> 
> 
> i forgot nothing ?  have i well posted ?

It looks OK, although I do not yet understand its significance.

There isn't any sign of your ENVY 5536 and I haven't any idea
what bbox is.

Is the ENVY *directly* connected to a USB port on the computer?

Cheers,

Brian.

Bug#1008997: cups: impossible to print on hp envy 5536 from sid

[Brian Potkin]

On Wed 06 Apr 2022 at 12:41:29 +0200, alain wrote:

> Package: cups
> Version: 2.4.1op1-2
> Followup-For: Bug #1008997
> X-Debbugs-Cc: compte.perso.de-al...@bbox.fr
> 
> alain@sid:~$ driverless
> 
> alain@sid:~$ sudo driverless
> [sudo] Mot de passe de alain :

Alain, please do not forget to Cc:

 Till Kamppeter 

Let's see where we get to with

   ippfind -T 10

and

   avahi-browse -rt _ipp._tcp

avahi-browse is in the avahi-utils package.

Cheers,

Brian.

Bug#1008997: cups: impossible to print on hp envy 5536 from sid

[Brian Potkin]

On Wed 06 Apr 2022 at 09:17:14 +0200, alain wrote:

> then , the command driverless or  sudo driverless gave me nothing .
> no return of the order .

Check that ipp-usb is installed with 'dpkg -l ipp-usb' and provide
what you get for

  systemctl status ipp-usb

and

  lsusb

Cheers,

Brian.

Bug#1008997: cups: impossible to print on hp envy 5536 from sid

[Brian Potkin]

severity 1008997 normal
tags 1008997 - upstream
thanks



On Tue 05 Apr 2022 at 19:10:14 +0200, alain wrote:

> Package: cups
> Version: 2.4.1op1-2
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: compte.perso.de-al...@bbox.fr
> 
> Hello.
> I'm writing to you because for the last week ,
> I have printing problems with cups.
> I can't get anything despite my research.
> I don't even have the test page.

Thank you for your report, Alain. However, it reads more like a request
for help rather than pointing to a a bug in the printing system. Still,
we can help you with that.

> Here is my research:
> https://debian-facile.org/viewtopic.php?id=31739
> old thread : (abandoned)
> https://debian-facile.org/viewtopic.php?id=31698
> 
> I thought, at the beginning, that the problem came from dpkg.
> because of the concomitance with its update.
> I asked the bts for help but it failed.
> Maybe I did too much?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008716
> 
> under bullseye stable, everything works perfectly.
> either under bookkworm or testing (tested quickly)
M
> and even more so, under sid (my distribution),
> nothing works. no way to print even a test page.
> 
> I tried everything, I can't get anything.
> That's why I write to you.
> Can you help me ?
> please ?
> Thank you.
> respectfully,
> alain .

Let's be clear; you are using unstable? Is the printer USB or network
connected?

Regards,

Brian.

Bug#1008175: -o sides=two-sided-long-edge always prints one-sided with lp & lpr

[Brian Potkin]

forwarded 1008175 https://github.com/OpenPrinting/cups/issues/359
tags 1008175 - moreinfo upstream
retitle 1008175 "-o sides=two-sided-long-edge always prints one-sided with lp & 
lpr"
thanks



On Sun 27 Mar 2022 at 18:33:37 -0500, r...@scotsgeek.com wrote:

> Brian:
> 
> > > PRINT_QUEUE_NAME is the actual name of the queue as given in Okular or
> > > by 'lpstat -a'.
> 
> Sorry! Was out at a pub with a friend before responding!  Should have
> waited! ;^)

The pub sounds the best of ideas :).
 
> driverless
> ipps://HP%20LaserJet%20Pro%20M148fdw%20(6CA573)._ipps._tcp.local/
> 
> As root:
> lpadmin -p testq -v
> "ipps://HP%20LaserJet%20Pro%20M148fdw%20(6CA573)._ipps._tcp.local/" -E -m
> everywhere
> 
> as regular user:
> lp -d testq -o sides=two-sided-long-edge lipsum.txt.pdf
> 
> Still printed single-sided

I have forwarded your report to upstream CUPS. One further piece of
information that could prove useful is attribures.txt. Obtain it with

  ipptool -tv "URI" get-printer-attributes.test > attributes.txt

and attach it to your next mail here.

Cheers,

Brian.

Bug#1008175: #1008175

[Brian Potkin]

On Sun 27 Mar 2022 at 15:13:30 -0500, r...@scotsgeek.com wrote:

> Brian:
> 
> avahi-browse -rt _ipp._tcp
> + enp2s0 IPv6 HP LaserJet Pro M148fdw (6CA573)  Internet Printer
> local
> + enp2s0 IPv4 HP LaserJet Pro M148fdw (6CA573)  Internet Printer
> local
> = enp2s0 IPv6 HP LaserJet Pro M148fdw (6CA573)  Internet Printer
> local
>hostname = [NPI6CA573.local]
>address = [192.168.1.207]
>port = [631]
>txt = ["mopria-certified=1.3" "mac=f8:b4:6a:6c:a5:73" "usb_MDL=HP
> LaserJet Pro M148f-M149f" "usb_MFG=HP" "TLS=1.2" "PaperMax=legal-A4"
> "kind=document,envelope,photo" "UUID=564e4733-5931-3235-3934-f8b46a6ca573"
> "Fax=T" "Scan=T" "Duplex=T" "Color=F" "note=unitedStates" 
> "adminurl=http://NPI6CA573.local./hp/device/info_config_AirPrint.html?tab=Networking=AirPrintStatus;

The text record advertises that the printer is capable of automatic
duplex ("Duplex=T").

[Snipped text]

> driverless
> ipps://HP%20LaserJet%20Pro%20M148fdw%20(6CA573)._ipps._tcp.local/

ipp://... is a URI for the printer. We will try setting up and printing
to a new print queue. Do

  lpadmin -p testq -v "URI" -E -m everywhere

Subdtitute URI with what is above. Test with

  lp -d testq -o sides=two-sided-long-edge test.pdf

> lpoptions -p PRINT_QUEUE_NAME -l
> lpoptions: Unable to get PPD file for PRINT_QUEUE_NAME: No such file or
> directory

PRINT_QUEUE_NAME is the actual name of the queue as given in Okular or
by 'lpstat -a'.

Cheers,

Brian.

Bug#1008175: #1008175

[Brian Potkin]

On Sun 27 Mar 2022 at 10:25:37 -0500, r...@scotsgeek.com wrote:

> The printer is"HP LaserJet Plus Pro M148fdw", connected by ethernet.
> 
> I first created a .txt file, then converted it to a .ps file, then converted
> to a .pdf file.  I then ran the following commands:
> lpr -o sides=two-sided-long-edge lipsum.txt.ps
> lp -o sides=two-sided-long-edge lipsum.txt.ps
> lpr -o sides=two-sided-long-edge lipsum.txt.pdf
> lp -o sides=two-sided-long-edge lipsum.txt.pdf
> 
> All printed one-sided.

Thanks for doing that.
 
> Then, as root, I ran the command
> cupsctl --debug-logging
> 
> Then as regular user, I ran:
> lp -o sides=two-sided-long-edge lipsum.txt.pdf
> 
> After many seconds, error reported:
> lp: Error - scheduler not responding.
> 
> No output to the printer.

Pass on this for the moment. My understanding is that there is no
difference in what lp and lpr do.
 
> I then ran:
> lpr -o sides=two-sided-long-edge lipsum.txt.pdf
> 
> It printed one-sided.
> 
> This used to work correctly, then a few months ago, it stopped working.  I
> had hoped it would have been corrected, but now I am reporting it.
> 
> Please let me know if I can help in any other way.

The error_log shows that two-sided-long-edge is sent to the printing
system. See argv[5]. It should then be sent on to the printer. The
printer supports two-sided-long-edge.

But we have

   [Job 238] Unable to do two-sided printing, setting sides to \'one-sided\'.

Now, where is that coming from and why? Investigating.

Rick, you can help with more information. Please give what you get for

  avahi-browse -rt _ipp._tcp
  driverless
  lpoptions -p PRINT_QUEUE_NAME -l

avahi-browse is in the avahi-utils package.

Cheers,

Brian.

Bug#1007110: cups printing dialogue: broad scrollbar overlaps with pull-down Icon

[Brian Potkin]

reassign 1007110 libreoffice-gtk3   

thanks



On Sun 27 Mar 2022 at 15:59:55 +0200, mh wrote:

> Hi
> 
> Can't you move it to where it belongs? libreoffice? gtk?
> Or do I really need to go through this whole reportbug thing?
> Is there a way for me to direct this already written report  to where
> it belongs?

I thought had sent it to libreoffice-gtk3 but forgot to tell the
control server.

Cheers,

Brian.

Bug#1007110: cups printing dialogue: broad scrollbar overlaps with pull-down Icon

[Brian Potkin]

reassign 1007110 libreoffice-gtk3
thanks.



On Fri 11 Mar 2022 at 13:26:52 +0100, Michael Hatzold wrote:

> Package: cups
> Version: 2.4.1op1-2
> Severity: normal
> 
> Dear Maintainer,
> 
> first, I file my bugreport against "cups" as I don't know to which exact
> package it really belongs. The bug shows up in the print dialogue.
> 
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> I wanted to print a document from within Libreoffice (gtk3)
> **
> apt policy libreoffice-gtk3
> libreoffice-gtk3:
>   Installiert:   1:7.3.1-1
> **
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I opened the document which I wanted to print and clicked the file/print menue
> 
>* What was the outcome of this action?
> printing menu opened.
> But when I tried to open one of the pulldown menue using  one of the little
> triangular icons on the right the hidden scrollbar popped up overlapping the
> icon which thus could not been activated.
> 
> Please Note:
> I use a much broader scrollbar than the default one. (I find the default
> ergonimically inapt). But this customisation was made one ore two years ago 
> and
> never effected negatively any menue in whatever program. Until today when I
> wanted to print. So there must have been a change recently which now changes
> the behavior.
> 
> 
>* What outcome did you expect instead?
> Obviously I do not want the scrollbar to overlap a region meant for operating 
> a
> menue and thus making it unusable.

Thank you for your report, Michael.

Print dialogs in an application are not the responsibility of the
printing system. Hence reassigning.

Regards,

Brian.

Bug#1008175: #1008175

[Brian Potkin]

tags 1008175 moreinfo
thanks


On Wed 23 Mar 2022 at 13:01:18 -0400, Rick Stanley wrote:

> Now neither option works correctly executing from the command line.
> "lpr -o sides=two-sided-long-edge  test.pdf"
> "lpr -o sides=one-sided  test.pdf"
> 
> And same for lp.

Thank you for your report, Rick. What is the printer make and model?

The situation is that neither command gives double-sided printing?
 
> Printing from Okular works correctly as expected.

There is a slight difference between your lp command and what Okular
does. Okular sends a PostScript file to the ptinter. Not that I can
see why that should make any difference, but printing from Evince or
Firefox sens a PDF. You could try that.

Anyway, let's have a log. Enable debug logging with

  cupsctl --debug-logging

Empty error_log with

  >/var/log/cups/error_log

Print and send error_log as an attachment after compressing it.

Regards,

Brian.

Bug#1008210: cups-client: lp (-h) hostname option has to come before destination (-d)

[Brian Potkin]

forwarded 1008210 https://github.com/OpenPrinting/cups/issues/357
tags 1008210 upstream
thanks



On Thu 24 Mar 2022 at 12:53:14 +0100, Paul Hutschemaekers wrote:

> Package: cups-client
> Version: 2.3.3op2-3+deb11u1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>* What led up to the situation?
>   I tried to print an file with the lp command* What exactly did you
> do (or not do) that was effective (or ineffective)?
>   I tried the command:
>   lp -d DESTINATION -h HOSTNAME FILENAME* What was the outcome of
> this action?
>   An error: lp: Error - The printer or class does not exist.
>* What outcome did you expect instead?
>   printing of the file.
> 
> When I print with:
>   lp -h HOSTNAME -d DESTINATION FILENAME
> everything works ok, I'm sure cups-client on BUSTER did not care about
> the placement of the host parameter. The man-page also reports
> lp  [  -E  ]  [  -U username ] [ -c ] [ -d
> destination[/instance] ] [ -h host‐name[:port] ]
> with the destination before the host-name

Thank you for your report, Paul. I can repeat your observations. Hence
forwarded upstream.

Regards,

Brian.

Bug#1008102: debian-reference: An addition to Table 5.1

[Brian Potkin]

Package: debian-reference
Version: 2.91
Severity: wishlist


I would suggest that iwd would be a useful addition to the list of
network configuration tools.

https://packages.debian.org/sid/iwd

Regards,

Brian.

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sun 13 Mar 2022 at 14:38:13 +0100, Daniel Gröber wrote:

[...]

> Here I also don't quite understand libgtk upstream. I assume the intention
> for the fallback is to have printing to at least work with some printers
> when cups isn't running/installed. While I think that's a terrible idea we
> still didn't want to break that behaviour since some users might now be
> depending on it.

There are users who depend on GTK's non-CUPS behaviour? Heaven help
them! They are expecting an experience divorced from what the the
printing system provides. They will possibly be shocked when using
bookworm.

The one thing GTK did correctly on buster and bullseye was handle
the shared queues of remote CUPS servers. On bookworm these are are
now inaccessible. A regression in its so-called "fallback" status?
I do not think I will lose much sleep over this :).

Regards,

Brian.

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sun 13 Mar 2022 at 17:07:19 +0100, d...@darkboxed.org wrote:

> On Sun, Mar 13, 2022 at 04:03:44PM +0000, Brian Potkin wrote:
> > Printing via a GTK destination to an IPP printer has never worked for
> > me. Even if printer information could be obtained, a Cairo-produced PDF
> > would go to the printer and PDF is not a PDL understood by it. In what
> > circumstances does such a destination work?
> 
> Believe it or not, some printers will actually accept straight up PDFs
> being piped into them without a PDL wrapper.

Hello Daniel,

I am unfamiliar with the term "PDL wrapper". Your input would be
welcome to clarify this.

I fully accept that a PDF sent *directly* to a printer with a PDF
interpreter should be printed. Are you saying the GTK dialog is
using this technique? Is this from obervation with your IPP printer?

Regards,

Brian.

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sun 13 Mar 2022 at 14:38:13 +0100, Daniel Gröber wrote:

> Hi Brian and Simon,
> 
> On Sat, Mar 12, 2022 at 08:56:38PM +0000, Brian Potkin wrote:
> > You have just confirmed that the printing system (CUPS + cups-filters
> > + (optionally) cups-browsed) works effieiently and as designed.
> > 
> > > Resultion: printing is still hell on earth :]
> > 
> > libgtk is not part of the printing system; 
> 
> Erm, sorry but it is part of the printing experience from a user's POV.

True.
 
> I wasn't trying to imply cups is the problem in fact if you read the
> backlog much of my frustration is with libgtk, but hell at least I'm here
> proposing patches so I feel I get to poke som fun at it. No offence
> intended Simon :)
> 
> Besides in the end it turned out libgtk with the right patch does work so
> *shrug*.

Having the GTK dialog on bullseye as a good citizen would be gratifying.
 
> > > - Printing via libgtk's fallback entry always fails
> > 
> > I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> > needed when the printing system does the jobi, as you have demonstrated?
> > On bullseye libgtk treads its own path and ignores the CUPS APIs. It is
> > little wonder users (like the bug submitter) experience consternation.
> 
> Here I also don't quite understand libgtk upstream. I assume the intention
> for the fallback is to have printing to at least work with some printers
> when cups isn't running/installed. While I think that's a terrible idea we
> still didn't want to break that behaviour since some users might now be
> depending on it.

I cannot provide code but can supply information. Perhaps there is some
enlightenment at

  https://bugzilla.gnome.org/show_bug.cgi?id=688956

This is what began the process. Comments 5 and 6 look interesting.

Printing via a GTK destination to an IPP printer has never worked for
me. Even if printer information could be obtained, a Cairo-produced PDF
would go to the printer and PDF is not a PDL understood by it. In what
circumstances does such a destination work?

Regards,

Brian.

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sat 12 Mar 2022 at 23:35:25 +, Simon McVittie wrote:

> On Sat, 12 Mar 2022 at 20:56:38 +0000, Brian Potkin wrote:
> > I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> > needed when the printing system does the jobi, as you have demonstrated?
> 
> cups upstream's medium to long term plan seems to be that toolkits like
> GTK and Qt should browse for mDNS printers themselves, and cups-browsed
> will eventually disappear, so that the only print queues shown are the
> ones manually configured in cups and the ones auto-discovered by the
> toolkits' print dialogs:
> 
> The intention of CUPS upstream is that the application's print dialogs
> browse the Bonjour broadcasts as an AirPrint-capable iPhone does,
> but it will take its time until all toolkit developers add the needed
> functionality, and programs using old toolkits or no toolkits at all,
> or the command line stay uncovered.
> — https://github.com/OpenPrinting/cups-filters

The github text is in /usr/share/doc/cups-filters/README.gz. Note that
it dates from the time of CUPS 1.6 when CUPS could not browse DND-SD
multicasts of CUPS servers and printers, and therefore would not make
queues and printers available locally. cups-browsed became essential
to do this. Without it, printing to a metwork queue would have been
tortuous, if not impossibel.
 
> In bullseye, cups-browsed is usually installed on desktop systems. The
> intention seems to be that the printers discovered by cups-browsed take
> precedence over the ones discovered by GTK, but in current bullseye this
> doesn't work reliably, and instead both sets appear as near-duplicates
> (see below).

Since CUPS 1.6 the need for cups-browsed has effectively disappeared.
Its major use now is to provide auto-setup of a local queue.

However, on bullseye, the GTK dialog  is not using the correct CUPS APIs
and queues have to be manually created or auto-setup by cups-browsed.

 
> In bullseye, if you print to the entries generated by GTK from mDNS,
> then GTK will submits a PDF via IPP directly to the printer, bypassing
> cups (and that doesn't always work, as seen here). In the implementation
> in bookworm, backported here as the versions with ~mr6 or ~mr6.1 in
> their names, GTK's fallback entries are implemented by asking the local
> instance of cups to set up a temporary print queue, and then submitting
> the job via IPP to that temporary queue, which seems to be more reliable
> in practice.

bookworm's libgtk does a much better job than buster's or bulleye's. On
bullseye the dialog displays "getting printer information" and never
does.

> So, if you think cups is always going to be better at IPP than GTK is,
> I hope you would agree that the ~mr6 or ~mr6.1 versions, which make more
> use of cups than the version currently in bullseye, are a better answer
> than what GTK in bullseye is currently doing?

I do agree with that.
 
> If the response to asking for testing of possible improvements is going
> to be people characterizing GTK as irretrievably inept, then that is
> not going to help me to find the time and motivation to work on making
> things better (the opposite, in fact).

I did not say or imply the situation was "irretrievable". I did use
"inept"; "suboptimal" might have been better :).

> In particular, if the changes I'm proposing are bringing GTK closer to
> what you want, which I think they are, then it seems counterproductive to
> discourage me from making them. Conversely, if you think these changes are
> wrong, please focus on proposing solutions rather than ascribing blame:
> that's a much more effective way to motivate volunteers to do as you ask.
> 
> > If I set up a manual destination, I would be extremely annoyed if it was
> > interfered with.
> 
> I believe the intention is that if there is a manually-configured queue,
> then any automatically-discovered entries that can be identified as being
> the same printer are ignored.

If you are referring to cups-browsed, that is correct.

> Also, if there is no manually-configured queue, but there is an
> automatically-discovered entry from cups-browsed, then the intention
> is that GTK uses that one, and any entries discovered by GTK that can
> be identified as the same printer are ignored. So as far as I can
> tell, it's aiming to do what you want: manual configuration "wins"
> vs. auto-detection, and cups-browsed's auto-detection "wins" vs. GTK's,
> so in each case, GTK is aiming to prioritize the cups printing system
> higher than its own code path.

cups-browsed is not required with the GTK dialog in bookworm. #908500.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908500

> The reason we're seeing duplicates seems to be that they

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sat 26 Feb 2022 at 19:43:08 +0100, Daniel Gröber wrote:

> Here are my test results:
> 
> TLDR:
> 
> - Printing via cups entry (be that cups-browsed or manual) always succeeds

You have just confirmed that the printing system (CUPS + cups-filters
+ (optionally) cups-browsed) works effieiently and as designed.
> 
> - Printing via libgtk's fallback entry always fails

I wouldn't see libgtk as providing a fallbac. Why would a fallback be
needed when the printing system does the jobi, as you have demonstrated?
On bullseye libgtk treads its own path and ignores the CUPS APIs. It is
little wonder users (like the bug submitter) experience consternation.

If it wasn't for cups-bowsed, we would be overrun with bug reports.
> 
> - Both proposed fixes work and succeed in removing the duplicate entry for
>   cups-browsed, but not for a manually added printer with default name or
>   when the user chooses a name that doesn't match the cups-browsed/libgtk
>   mangling scheme.

If I set up a manual destination, I would be extremely annoyed if it was
interfered with.

> Resultion: printing is still hell on earth :]

libgtk is not part of the printing system; it is a helper program. It
says - here are some destinations, click on them and I will do your
prinring. Problem: it does not live up to its promises and hasn't for
many years. It is inept. So let's have the source of this bug on
bullseye correectly and fairly and squarly identified. It is libgtk.
That is your hell :).

BTW, whoever said Qt is more competent hasn't looked at how it behaves
without cups-browsed.

With thanks to Simon McVittie and everyone else for caring.

Regards,

Brian.

Bug#969531: avahi-daemon: retrieving printer info blocks printing until shutdown

[Brian Potkin]

On Fri 04 Sep 2020 at 15:23:32 +0200, Michael Hatzold wrote:

> OKI printer B432, conected via USB, no network cable attached.

The B432 is an IPP device; it very likely understands the IPP-over-USB
protocol.

When connected to USB the ipp-usb service is started and ipp-usb takes
control of the only available USB interface.
> 
>* What led up to the situation?
> Want to print
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> select document, start print dialog, select my printer (config was done via
> CUPS);

Your manually configured iprinter is not being allowed to access the
USB interface. This is not a bug. Please see sections 14, 15 and 16 at

  https://wiki.debian.org/CUPSDriverlessPrinting
  
> Now the printer appears a second time in the list with a different entry. If I
> select this new entry, I am asked for CUPS PW twice, then it (a deamon,
> whatever) starts retriving printer info which *never* completes.

That was a GTK bug at the time. 

>* What was the outcome of this action?
> Either way, selecting my own entry or the new one made by the daemon, the
> printer does nothing (I waited up to 45 minutes... until I shutdown my system.
> Them during shutdown, there is a pause during which the document gets printed.

Pass.
 
>* What outcome did you expect instead?
> I want the printer to print after I sent the job.
> 
> 
> *** End of the template - remove these template lines ***
> 
> There is a workaround:
> 
> In the original /etc/avahi/avahi-daemon.conf file, there is an entry "#allow-
> interfaces=eth0".
> Changing and uncommenting it to "allow-interfaces=eth9" solves the problem
> (printer not conected via ethXYZ, though). 

"allow-interfaces=eth9" effectively prevents avahi-daemon from working
on all interfaces, including the loopback interface. ipp-usb is exposed
on the loopback interface by default.

avahi-daemon is now completely crippled; it may as well be purged from
the system.

>Therefor I assume this hides a bug
> or an improper default configuration.

There isn't any bug in avahi-daemon.

Regards,

Brian.

Bug#1006892: cups-browsed: Local queues are not created for discovered printers

[Brian Potkin]

tags 1006892 moreinfo
tags 1006892 normal
thanks.


On Mon 07 Mar 2022 at 18:32:10 +0100, Grzesiek11 wrote:

> Package: cups-browsed
> Version: 1.28.12-1
> Severity: important

[...]

> `cups-browsed` can no longer create local queues for discovered
> printers, because root (which the daemon runs as) now has no implicit
> permission in `cupsd` to do so. It is now required for root to be in
> the `lpadmin` group or to be otherwise explicitly allowed.
> 
> See https://github.com/OpenPrinting/cups/issues/306 for details

Thank you for your report, Grzesiek11.

Please look at #1006727:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006727

Does that answer your needs?

Regards,

Brian.

Bug#1006853: cups-browsed: HTTP Forbidden when adding printer with cups-browsed

[Brian Potkin]

On Mon 07 Mar 2022 at 11:15:26 +, Brian Potkin wrote:

> tags 1006853 moreinfo
> thanks
> 
> 
> 
> On Sun 06 Mar 2022 at 21:34:08 +0100, Mark Brandis wrote:
> 
> > Package: cups-browsed
> > Version: 1.28.12-1
> > Severity: normal
> > X-Debbugs-Cc: mark.bran...@posteo.de
> > 
> > I use a Epson XP 8600 printer, which cups found just fine and added
> > automatically as a printer queue, until recently. For a few days now, cups 
> > has
> > not added the printer as a queue, unless the printer was online during boot.
> > 
> > Searching in the logs I found the following:
> 
> [...]
> 
> > ==> error_log <==
> > E [06/Mar/2022:21:30:15 +0100] [Client 406] Returning HTTP Forbidden for 
> > CUPS-
> > Add-Modify-Printer (ipp://localhost/printers/EPSON_XP_8600_Series) from
> > localhost
> 
> Thank you for you report, Mark. Is the connection USB or network?

The connection type doesn't matter; I can now replicate your observation.

Edit /etc/cups/cups-files.conf to have

  SystemGroup lpadmin root

and restart cups.

Regards,

Brian.

Bug#1006853: cups-browsed: HTTP Forbidden when adding printer with cups-browsed

[Brian Potkin]

tags 1006853 moreinfo
thanks



On Sun 06 Mar 2022 at 21:34:08 +0100, Mark Brandis wrote:

> Package: cups-browsed
> Version: 1.28.12-1
> Severity: normal
> X-Debbugs-Cc: mark.bran...@posteo.de
> 
> I use a Epson XP 8600 printer, which cups found just fine and added
> automatically as a printer queue, until recently. For a few days now, cups has
> not added the printer as a queue, unless the printer was online during boot.
> 
> Searching in the logs I found the following:

[...]

> ==> error_log <==
> E [06/Mar/2022:21:30:15 +0100] [Client 406] Returning HTTP Forbidden for CUPS-
> Add-Modify-Printer (ipp://localhost/printers/EPSON_XP_8600_Series) from
> localhost

Thank you for you report, Mark. Is the connection USB or network?

Regards,

Brian.

Bug#1006468: cups: misleading documentation regarding root login credentials

[Brian Potkin]

tags 1006468 patch
thanks



On Fri 25 Feb 2022 at 17:02:06 -0500, Celejar wrote:

> Package: cups
> Version: 2.4.1op1-1
> Severity: normal
> 
> Hello,

Thank you for your report, Celejar.
 
> On a fresh CUPS install, I logged into the web interface as root to add
> a printer, and was denied with a 401 Forbidden error. The problem seems
> to be that root is not a member of a group in @SYSTEM (which by default
> only includes lpadmin). I understand that Debian has decided that this
> is not a bug:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616718
> 
> but Debian's documentation seems quite misleading and inconsistent on
> this point.
> 
> README.Debian states:
> 
> 'Administration' is where you need to be to set up a local print queue.
> At some point you will be required to authenticate. A User Name of 'root'
> and root's password is always acceptable. Any other user must be a member
> of the lpadmin group.
> 
> This clearly indicates that root does *not* need to be a member of the
> lpadmin group.

This is an accurate reflection of the situation for Debian distributions
up to and including bullseye. It is not the case on bookworm with cups
2.4.1op1-1. Please see #1006727:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006727
 
> OTOH, 'man cupsd.conf' is more accurate:
> 
> Note: The 'root'  user  is  not special and must be granted privileges
> like any other user account.
> 
> I suggest that the language of the README be modified to resemble that
> of the man page.

The thrust of the README is to point out that a user needs to be a
member of the lpadmin group, so a possible documentation change is:

  'Administration' is where a user needs to be to set up a local print
   queue. At some point authentication will be required. For this to
   be successful the user must be a member of the lpadmin group.

The assumption here is that "SystemGroup root lpadmin" is implemented.

Regards,

Brian.

Bug#1006727: cups-daemon: /etc/cups/cups-files.conf and SystemGroup

[Brian Potkin]

Package: cups-daemon
Version: 2.4.1op1-1
Severity: normal
Tags: patch


When working as root it is not possible to add or remove a queue. The
error messgae is

  lpadmin: Forbidden

A solution is to add "root" to the SystemGroup line.

Regards,

Brian.

Bug#983349: sane-escl fails with an ENVY 5530 on bullseye

[Brian Potkin]

On Sun 29 Aug 2021 at 10:12:42 +0200, alain wrote:

> hplip seems to be not compatible with debian sid .

Hello Alain,

This is incorrect. You are able to scan with airscan. A limitation in
the ENVY's hardware prevents scanning with hpaio. This is unavoidable
when ipp-usb is active. It is not a bug in libsane1, hplip or ipp-usb.

You should also have been able to scan with escl but were not able to
do so. This would have been a bug in escl at the time you made your
first report.

What we need to know now is whether the bug is still present in version
1.1.1-4 of libsane1 in Debian sid.

Bring your sid OS up to date and do

  simple-scan escl:http://127.0.0.1:6

Check that http://127.0.0.1:6 is correct using 'scanimage -L'.

Cheers,

Brian.

Bug#942190: closed by Brian Potkin (Re: Bug#942190: cups: Memory leak for WIFI enabled printer.)

[Brian Potkin]

On Tue 11 Jan 2022 at 02:06:22 +0100, Mladen Mijatov wrote:

> I've been notified in the meantime by a developer on the project that
> my particular printer doesn't require HP's drivers and that open
> source ones will suffice. After removing HP's drivers and relying on
> open source drivers all of my issues with this printer went away,
> including memory leaks on CUPS. 

Good to know.

> Sorry for not replying, email must have gotten lost.

Not to worry. Thank you again for your report and for engaging with
the issue.

Regards,

Brian.

Bug#555361: hplip: Embedded code copy of python-pexpect

[Brian Potkin]

On Tue 11 Jan 2022 at 08:07:35 +0800, Paul Wise wrote:

> Control: reopen -1
> Control: found -1 3.21.8+dfsg0-2
> 
> On Mon, 2022-01-10 at 20:54 +, Brian Potkin wrote:
> 
> > Use of our limited, volunteer supported resources is best served by not
> > keeping open inactive bugs any longer than desirable, especially in
> > cases where the package concerned is older than the current stable
> > Debian version and upstream support has been limited. Consequently, the
> > report is now being closed.
> 
> This is not very respectful of our users and social contract.
> 
> Users should be given the opportunity to reproduce old bugs before they
> are summarily closed without any attempt at reproducing them. Old bugs
> are extremely likely to still be present, them being open usually means
> no-one bothered to look at and fix them, at least in my experience.
> 
> The social contract states that we should not hide bugs. Closing old
> bugs without attempting to verify if they are fixed or giving users the
> opportunity to do so is definitely hiding bugs.
> 
> https://www.debian.org/social_contract
> 
> When the bug is trivial to verify if it is still present or not,
> you should at very least run the two commands needed to do that:
> 
> $ chronic apt source hplip
> $ find -iwholename '*expect*'
> ./hplip-3.21.8+dfsg0/base/pexpect
> ./hplip-3.21.8+dfsg0/base/pexpect/__init__.py
> 
> Please also notify the security team of the embedded copy:
> 
> https://wiki.debian.org/EmbeddedCopies

Thank you for reopening the report. The security team appears to be
aware of the embedded copy.

https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies

Regards,

Brian.

Bug#998318: cups-client: lpoptions ignores and deletes settings of printer instances in ~/.cups/lpoptions

[Brian Potkin]

On Sun 07 Nov 2021 at 19:31:54 +0100, mtemp...@zimprich.info wrote:

> 
> > > * any attempt to modify printer instance settings using "lpoptions -p
> > > laserjet5si/konzept -o InputSlot=Upper" results in deletion of all
> > > "Dest" lines previously present within lpoptions file and modification
> > > of the single line that was considered to be affected
> > Not quite my observation. I cannot set up more than one instance. Adding
> > a second one witj lpoptions deletes the existing one. You show five
> > lines in your example. Was ~/.cups/lpoptions edited by hand?
> > 
> 
> For clarification:
> The  ~/.cups/lpoptions file cited above has been extracted from a backup
> taken before upgrade towards debian bullseye (minus potential but in case
> present unintentional modifications while copy-pasting from the backup).
> It is being rewirtten in the same way you reproduced above upon any attempt
> to issue an "lpoptions -p" command with the new CUPS installation.
> 
> Thanks for keeping tracks of this issue.

Upstream has responded at

  https://github.com/OpenPrinting/cups/issues/282

and asked

  Would you mind applying the patch and telling me whether 
  it helps with your issue?

Applying patches and rebuilding is not in my skill set. Can you help out
here, Martin? Thorsten?

Cheers,

Brian.

Bug#998318: cups-client: lpoptions ignores and deletes settings of printer instances in ~/.cups/lpoptions

[Brian Potkin]

tags 998318 upstream
forwarded 998318 https://github.com/OpenPrinting/cups/issues/282
thanks



On Tue 02 Nov 2021 at 11:42:31 +0100, Martin Zimprich wrote:

> Package: cups-client
> Version: 2.3.3op2-3+deb11u1
> Severity: normal
> 
> Dear Maintainer,

That's not me, Martin, but we thank you for your comprehensive report.
 
> after upgrade from to Debian buster to bullseye (cups-client 2.2.10-6
> to 2.3.3op2) the lopptions does not properly handle printer instances
> defined in ~/.cups/lpoptions

Agreed.

> Symptoms:
> * "lpoptions -p laserjet5si/konzept -l" gives the same output as
> "lpoptions -p laserjet5si/manuell -l" (namely the default printer
> settings made in CUPS) while lpoptions file defines different settings
> for both of these instances (see example file below)

It appears that an instance is inheriting options from the main queue.
This is not supposed to happen. An instance is also not shown in the
output of 'lpstat -a'.

> * any attempt to modify printer instance settings using "lpoptions -p
> laserjet5si/konzept -o InputSlot=Upper" results in deletion of all
> "Dest" lines previously present within lpoptions file and modification
> of the single line that was considered to be affected

Not quite my observation. I cannot set up more than one instance. Adding
a second one witj lpoptions deletes the existing one. You show five
lines in your example. Was ~/.cups/lpoptions edited by hand?

> * third party applications such as Okular (4:20.12.3-2) are not able
> to display or use any printer instance defined * downgrade to
> cups-client 2.2.10 and according dependencies seems to bypass the
> problem and allows the very same third party applications to display
> and use printer instances again

I spent little time on this. Partly because buster's Firefox did not
display instances for me and partly because I am wary of trusting an
app's dialog to do the right thing.
 
> -- example ~/.cups/lpoptions file in use:
> 
> Default bx310fn
> Dest laserjet5si/blank_duplex Duplex=DuplexNoTumble InputSlot=LargeCapacity
> Dest laserjet5si/konzept InputSlot=Upper 
> Dest laserjet5si/manuell InputSlot=Manual
> Dest P6021cdn InputSlot=MF1

Debian 10 has CUPS 2.2.10. The following link describes very similar
observations to ours when CUPS 2.2.12 is used:

  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240183 

Regards,

Brian.

Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)

[Brian Potkin]

On Tue 26 Oct 2021 at 10:49:59 -0400, Brendon Higgins wrote:

> Hi Brian,
> 
> On Tuesday, October 26, 2021 8:13:01 A.M. EDT Brian Potkin wrote:
> > On Mon 25 Oct 2021 at 16:07:36 -0400, Brendon Higgins wrote:
> > > Hi Brian,
> > > 
> > > Perhaps I was unclear in my description. You responded:
> > > > You want to replace hp-plugin
> > > 
> > > On the contrary, I would think the proposed hplip-plugin-installer package
> > > would pre-depend on hplip and essentially just run hp-plugin in its
> > > postinst. It's complementary, not a replacement.
> > > 
> > > > with something Debian-specific that Debian has to maintain for ever.
> > > 
> > > Debian-specific, perhaps, though hardly beyond ordinary packaging
> > > practices. Could be useful for derivatives, too. I would think
> > > maintenance for such a simple thing would be minimal (barring major
> > > upstream changes - which users would have to figure out for themselves,
> > > otherwise).
> > > 
> > > And as I mentioned, there's plenty of precedent for this approach, and the
> > > arguments against those are the same.
> > 
> > It strikes me that an hplip-plugin-installer package would not provide
> > anything over and above what hp-plugin provides. This checksum issue
> > reported in Launchpad #1948555 is not uncommon and such a package
> > would not alleviate it. The usual way to tackle it is download the
> > plugin and install with 'sh '.
> 
> Download the plugin from where? I traced its source to the location given in 
> that Launchpad bug, and it's obviously a broken upload at the server - this 
> is 
> a "true negative" checksum failure. (Please try it - it still hasn't been 
> fixed 
> as of writing.) I haven't been able to uncover an alternative download 
> location, so if you know of one I would love to hear it (really!).

The official archive site is

  https://developers.hp.com/hp-linux-imaging-and-printing/plugins

OpenPrinting provides a mirror as a service to users. A problem with it
is a problem for OpenPrinting. 'sh ' is upstream's advice
when hp-plugin doesn't behave.
 
> This negative experience is what inspired me to suggest hp-plugin-installer - 
> because it does provide key usability benefits due to this property: it would 
> run at the same time that the hplip packages are updated. The benefits that 
> come from this are:

You are are not the first (nor will you be the last) to have a problem
installing a plugin. This is upstream's responsibility.

> 1. Automatic updating of the plugin to the corresponding version - which, 
> assuming an environment that uses one of the affected devices, is implicitly 
> required by the hplip package for it to be at all useful.

This is one of my sticking points. Automatic? A user has a device that
requires a non-free plugin for scanning. The user never scans, but is
still obliged to download and install it.

> 2. Any failure to download/install the updated plugin can be found and 
> addressed by the system administrator immediately. This is in contrast to the 
> current situation where the system is left in an incomplete, unusable state, 
> for an indefinite period of time, until the user might try to use their 
> device, 
> encounter a problem, and the user (rather than system administrator) is 
> expected to fix that.
> 
> In my case, the plugin file being broken upstream was my critical failure 
> point. I only encountered this weeks after the hplip packages updated - it 
> seems to me that the plugin file might have been okay back then. (I've since 
> had to downgrade back to stable's version.) But I can imagine other 
> situations 
> which would be helped by hp-plugin-installer, too - perhaps the system is 
> portable and not always connected to the internet, so downloading the plugin 
> at any given time (even if it is good upstream) is not feasible, but 
> downloading it when packages are also downloaded and installed makes much 
> more 
> sense. Or perhaps the user has been granted printing permissions but not root 
> permissions by the system administrator - the sysadmin would absolutely want 
> some kind of automation to install this plugin in such a situation...
> 
> > There is also the matter of what runs the proposed package. It cannot
> > be from any of the HPLIP packages because, as the Debian Policy Manual
> > says:
> > 
> >   In addition, the packages in main must not require or recommend
> >   a package outside of main for compilation or execution...
> 
> hplip could suggest it, though. At any rate, I imagine the sysadmin would 
> install hp-plugin-installer (from contrib) themselves. They wo

Bug#997795: closed by Brian Potkin (Re: Bug#997795: hplip: Make a hplip-plugin-installer package)

[Brian Potkin]

On Mon 25 Oct 2021 at 16:07:36 -0400, Brendon Higgins wrote:

> Hi Brian,
> 
> Perhaps I was unclear in my description. You responded:
> > You want to replace hp-plugin
> 
> On the contrary, I would think the proposed hplip-plugin-installer package 
> would pre-depend on hplip and essentially just run hp-plugin in its postinst. 
> It's complementary, not a replacement.
>
> > with something Debian-specific that Debian has to maintain for ever.
> 
> Debian-specific, perhaps, though hardly beyond ordinary packaging practices. 
> Could be useful for derivatives, too. I would think maintenance for such a 
> simple thing would be minimal (barring major upstream changes - which users 
> would have to figure out for themselves, otherwise).
> 
> And as I mentioned, there's plenty of precedent for this approach, and the  
> arguments against those are the same.

It strikes me that an hplip-plugin-installer package would not provide
anything over and above what hp-plugin provides. This checksum issue
reported in Launchpad #1948555 is not uncommon and such a package
would not alleviate it. The usual way to tackle it is download the
plugin and install with 'sh '.

There is also the matter of what runs the proposed package. It cannot
be from any of the HPLIP packages because, as the Debian Policy Manual
says:

  In addition, the packages in main must not require or recommend
  a package outside of main for compilation or execution...

Ultimately, it is the user's responsibility to download a non-free plugin.

Cheers,

Brian.

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Brian Potkin]

On Thu 21 Oct 2021 at 20:39:01 +0200, Fabian Greffrath wrote:

> Am Donnerstag, dem 21.10.2021 um 18:33 +0100 schrieb Brian Potkin:
> > I think this is exactly the way it was designed. Whether the design
> > is the best is what has been brought up in this report.
> 
> The results are pretty surprising and unpredictable, though.

Indeed. Many users, myself included, have stared at the choices and
wondered what the first choice implies. "Default - Gnome" next to it
might have helped.

Fortunately, not selecting it isn't of any consequence. A user gets
what else is chosen.
 
> > There is the concept of "default desktop". At the present time it is
> > Gnome. The first selection is for the default. The description for
> > task-desktop says:
> 
> You don't have a chance to read the description of the task-desktop
> package during d-i. As Holger already stated, it must be made clear
> that merely selecting "Desktop Environment" will have the same effect
> as selecting the first one in the list, even if this has been
> explicitly unselected.

No, that is not the case. Selecting "Desktop Environment" only will
have the effect of selecting the default desktop. This could be Xfce,
which is not the first one in the list.

Cheers,

Brian.

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Brian Potkin]

On Thu 21 Oct 2021 at 17:27:22 +0200, Fabian Greffrath wrote:

> Hi Holger,
> 
> thanks for your reply!
> 
> Am 21.10.2021 16:31, schrieb Holger Wansing:
> > Selecting "Desktop Environment", but not choose one of the displayed
> > possiblities (like "GNOME", "KDE" and so on) is not the way, how this
> > dialog was designed, I guess.
> 
> Yes, apparently. :/

I think this is exactly the way it was designed. Whether the design
is the best is what has been brought up in this report.

There is the concept of "default desktop". At the present time it is
Gnome. The first selection is for the default. The description for
task-desktop says:

  This task package is used to install the Debian desktop.

Regards,

Brian.

Bug#604839: Bug#988472: Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 09 Oct 2021 at 11:21:54 +0200, Holger Wansing wrote:

> Hi,

Hello Holger,

Thank you for your consideration

> Brian Potkin  wrote (Sun, 3 Oct 2021 14:45:29 +0100):
> >  > You should be able to see to which device the USB stick was mapped
> >  > by running the command dmesg after inserting it.
> > 
> > I would add lsblk, with a link to its manual page.
> > 
> >  You should be able to see to which device the USB stick was mapped
> >  by running the command lsblk before and after inserting it. The
> >  output of dmesg (as root) is another discovery method.
> 
> Ok, applied (similar).

Looks good.
 
> > --
> > 
> >  > If you use the wrong device the result could be that all information
> >  > on for example a hard disk could be lost.
> > 
> > Surely it would be quite surprising if all information was not lost?
> > Why not continue the dire warning, particularly as the process is done
> > as root? "would" instead of "could"?
> 
> I would simplify that to 
> "If you use the wrong device the result could be that all
> information on for example a hard disk is lost."

Sorry, it appears I wasn't very clear. What I wrote was not intended as
replacemet text but a short commentary on whether there is a possibility
or a certainty of data being lost. Changing one word in your text and
putting in a couple of commas:

  "If you use the wrong device the result will be that all
   information on, for example, a hard disk is lost."

> > -
> > 
> >  > Debian installation images for this architecture are created using
> >  > the “isohybrid”...
> > 
> > I do not understand why "isohybrid" needs to be enclosed in double
> > quotes. Two links:
> 
> Ok, I replaced the quotes by a bold font.

Better.
 
> >   https://joeyh.name/blog/entry/Debian_USB_install_from_hybrid_iso/
> >   https://blog.einval.com/2011/01/07
> > 
> > I have forgotten whether the Guide policy allows referencing pages
> > outside the Debian infrastructure.
> > 
> > -------
> > 
> >  > If you have chosen the mini.iso to be written the USB stick, the
> >  > second partition doesn't have to be created, as - very nice - ...
> > 
> > The original ("very nicely") is OK and better English (IMO).
> 
> Ok, applied.

Thanks.


> Brian Potkin  wrote (Sun, 3 Oct 2021 15:51:28 +0100):
> > On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:
> > 
> > [...]
> > 
> > > I had some understanding issues, mostly in chapter
> > > "Manually copying files to the USB stick — the flexible way"
> > 
> > I have never really understood what is so special about syslinux and
> > mbr.bin in the context of using hd-media. GRUB should always be at
> > hand on a Linux machine. This is my flexible way:
> > 
> > 1. dd if=/dev/zero of=/dev/sdb count=100
> >(Could be omitted).
> > 
> > 2. cfdisk /dev/sdb (FAT).
> > 
> > 3. mkfs.vfat /dev/sdb1
> >dosfslabel /dev/sdb1 LABEL.
> >(Download dosfstools).
> > 
> > 4. mount /dev/sdb1 /mnt
> >grub-install --boot-directory=/mnt/boot /dev/sdb
> > 
> > 5. cp vmlinuz /mnt/boot
> >cp initrd.gz /mnt/boot
> > 
> > 6. cp  /mnt
> > 
> > 7. # An example grub.cfg.
> >menuentry 'Debian 11.0.0' {
> >linux /boot/vmlinuz shared/ask_device=manual \
> >shared/enter_device=/dev/disk/by-label/LABEL
> >initrd /boot/initrd.gz
> >}
> > 
> > 8. cp grub.cfg /mnt/boot/grub
> > 
> > 9. Boot.
> > 
> > More detail at https://wiki.debian.org/Installation+Archive+USBStick.
> > To declare an interest - I wrote that page.
> 
> I personally have no strict preference on syslinux.
> However, the proposed alternative does not look much easier to me ...
> (leaving only the pro, that syslinux does not need to be installed)
> 
> 
> Other opinions?
> 
> 
> 
> 
> Brian Potkin  wrote (Sun, 3 Oct 2021 19:40:00 +0100):
> > On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:
> > 
> > [...]
> > 
> > > - Because a long time has passed by since the last overhaul of this 
> > > chapter,
> > >   maybe there is some more, that could be changed, for example because of
> > >   changed/new technology or experience?
> > 
> > Regardin

Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:

[...]

> - Because a long time has passed by since the last overhaul of this chapter,
>   maybe there is some more, that could be changed, for example because of
>   changed/new technology or experience?

Regarding 4.3.2. at

  
https://people.debian.org/~holgerw/installation-guide_2021-10-02/amd64/ch04s03.html


 > An alternative way to set up your USB stick is to manually copy
 > the installer files,...

This section has been about since the dawn of time :). It predates the
advent of isohybrid technology and could be said to have served its
purpose and be retired. An alternative would be to leave it there and
introduce it as follows:

 Prior to isohybrid technology being used for all Debian ISOs, this way
 was the method used to boot from a USB device. It has been superseded
 by the technique in Section 4.3.1 [LINK] but has been left here for
 educational and  historical purposes and in case it proves of use to a
 user.



 > ...(smaller setups are possible if you follow Section 4.3.3,...

I wonder about this. The Debian 11 netinst ISO is 480M. GRUB plus the
boot files are 33M. Would they fit on a 512M USB stick (which is not
really 512M)? Partially tested to say "no". My rule of thumb is 1G.



The link beginning

  http://http.us.debian.org/

should be

  http://deb.debian.org/

or

  https://deb.debian.org/



The Note exercised my mind. It has nothing to do with the being able to
use this method but refers to an after effect. "major disadvantage"
refers to this after effect. An alarming term.

 > Note that, although convenient and successful, this method does have a
 > drawback affecting how the size of the USB device is seen because it
 > sets its logical size to 1 GB, even if the capacity of the USB stick is
 > larger. You will need to repartition the USB stick and create new file
 > systems to get its full capacity back if you ever want to use it for
 > some different purpose.



Regards,

Brian.
 

Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:

[...]

> I had some understanding issues, mostly in chapter
> "Manually copying files to the USB stick — the flexible way"

I have never really understood what is so special about syslinux and
mbr.bin in the context of using hd-media. GRUB should always be at
hand on a Linux machine. This is my flexible way:

1. dd if=/dev/zero of=/dev/sdb count=100
   (Could be omitted).

2. cfdisk /dev/sdb (FAT).

3. mkfs.vfat /dev/sdb1
   dosfslabel /dev/sdb1 LABEL.
   (Download dosfstools).

4. mount /dev/sdb1 /mnt
   grub-install --boot-directory=/mnt/boot /dev/sdb

5. cp vmlinuz /mnt/boot
   cp initrd.gz /mnt/boot

6. cp  /mnt

7. # An example grub.cfg.
   menuentry 'Debian 11.0.0' {
   linux /boot/vmlinuz shared/ask_device=manual \
   shared/enter_device=/dev/disk/by-label/LABEL
   initrd /boot/initrd.gz
   }

8. cp grub.cfg /mnt/boot/grub

9. Boot.

More detail at https://wiki.debian.org/Installation+Archive+USBStick.
To declare an interest - I wrote that page.

Regards,

Brian.

Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:

> Hi,

Hello Holger,
 
> I'm thinking about (long overdue) updating chapter 
> https://d-i.debian.org/doc/installation-guide/en.amd64/ch04s03.html
> "Preparing Files for USB Memory Stick Booting".

I am working from

  https://people.debian.org/~holgerw/

and will devote this mail to comments on the introductory section and
section 4.3.1.


 > You should be able to see to which device the USB stick was mapped
 > by running the command dmesg after inserting it.

I would add lsblk, with a link to its manual page.

 You should be able to see to which device the USB stick was mapped
 by running the command lsblk before and after inserting it. The
 output of dmesg (as root) is another discovery method.

--

 > If you use the wrong device the result could be that all information
 > on for example a hard disk could be lost.

Surely it would be quite surprising if all information was not lost?
Why not continue the dire warning, particularly as the process is done
as root? "would" instead of "could"?

-

 > Debian installation images for this architecture are created using
 > the “isohybrid”...

I do not understand why "isohybrid" needs to be enclosed in double
quotes. Two links:

  https://joeyh.name/blog/entry/Debian_USB_install_from_hybrid_iso/
  https://blog.einval.com/2011/01/07

I have forgotten whether the Guide policy allows referencing pages
outside the Debian infrastructure.

---

 > If you have chosen the mini.iso to be written the USB stick, the
 > second partition doesn't have to be created, as - very nice - ...

The original ("very nicely") is OK and better English (IMO).

---

Regards,

Brian.

Bug#995322: closed by Brian Potkin (Re: Bug#995322: ipp-usb: prevents hp-toolbox and libsane-hpaio from working)

[Brian Potkin]

On Thu 30 Sep 2021 at 08:57:13 +0200, Giacomo Mulas wrote:

> On Wed, 29 Sep 2021, Debian Bug Tracking System wrote:
>
> > #995322: ipp-usb: prevents hp-toolbox and libsane-hpaio from working
> >
> > It has been closed by Brian Potkin .
> >
> > Much of your time would have been saved by reading the Release
> > Notes. Please submit another report if you feel the documentation
> > is inadequate.
>
> Indeed it is. As I said, ipp-usb got automatically installed upon upgrading
> to bullseye, together with tons of other packages. The only piece of
> information I was shown was the NEWS.Debian file of ipp-usb (together with
> dozens of other messages). The only thing it says is "Existing or newly
> created queues on a USB connection for IPP-over-USB
> capable devices using vendor drivers will not work while the ipp-usb
> service is activated and managing the connection."
> This is only about printing, no clue about other functions of the same
> device.

ipp-usb is a recommended package for cups-daemon and libsane1. That
the NEWS file does not mention scanning is a fair point. Does the
addotion of a third paragrapgh allay your concern?

If so, I woud suggest subnitting a report against ipp-usb. The change
is not extensive and could make it into a bullseye point release.

---

ipp-usb uses the IPP-over-USB protocol to allow the setting up of a
driverless print queue for most USB connected modern multi-function
and a few modern USB-only devices. The default is to auto-setup the
queue with cups-browsed.

Existing or newly created queues on a USB connection for IPP-over-USB
capable devices using vendor drivers will not work while the ipp-usb
service is activated and managing the connection.

The same protocol also allows discovery of modern scanner devices via
libsane1. Oncve again, vendor drivers will not work while the ipp-usb
service is activated and managing the connection.

Details are at

https://wiki.debian.org/CUPSDriverlessPrinting

---

BTW, Xsane should have given you two backends to access. hpaio will
not work bit escl should. I guess that was not the case. That is a bug
in escl and why the wiko points to sane-airscan as an alternative.

> Only _after_ discovering that ipp-usb was preventing xsane to
> connect to the scanner I looked at
> https://wiki.debian.org/CUPSDriverlessPrinting
> and found this warning in there:
> "Note that IPP-over-USB reserves the USB interface connection with the
> printer/scanner exclusively for itself and communication with a
> printer/scanner device by software that does not operate using the
> IPP-over-USB protocol becomes impossible while ipp-usb is running.  This is
> a consequence of the design of USB communication.  It is not a bug in
> ipp-usb.  (omissis) Communicating with a USB connected scanner via classic
> SANE backends such as libsane-hpaio, sane-pixma or sane-epson2 also becomes
> impossible with the ipp-usb daemon active and running."
>
> Had I seen _this_ warning in the release notes, _then_ this would have got
> some alarm ringing and I would not have wasted hours tracking this.
>
> So, please: do include the above warning, in full, in the release notes of
> ipp-usb.

I think that duplicating in the Release Notes what is on the wiki is not
the way to go, but you could submit a bug against the release-notes
pseudo-package.

> Also, it would be helpful to add at least a "Suggests" to install also the
> package sane-airscan along with it, since this will restore most
> multifunction devices to properly work again as scanners when ipp-usb is
> running.

That would be for the libsane1 maintainer to consider. Note that he has
already declined to make sane-airscan a Recommends:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971658

Cheers,

Brian.

Bug#994839: ch-upgrading.en.html#sufficient-space: a suggestion.

[Brian Potkin]

Package: release-notes
Severity: normal
Tags: patch



At

  
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#sufficient-space

steps 1, 2 and 3 for using a temporary /var/cache/apt/archives work
fine for me. At step 4 I do 'mount' and get

 /dev/sdc1 on /media/usbkeys type ext4 (rw,relatime)
 /dev/sdc1 on /var/cache/apt/archives type ext4 (rw,relatime)

It would seem to me that step 4 should be advising

  umount /var/cache/apt/archives

Cheers,

Brian.

Bug#839400: hplip: setup of HPLIP toolbox is faulty

[Brian Potkin]

On Sat 01 Oct 2016 at 09:00:39 -0400, WRMelgaard wrote:

> Package: hplip
> Version: 3.14.6-1+b2
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> Previously installed version was done manually from HP website, decided to 
> use the Debian packag system for upgrade
> Using Synaptic, installed the hplip package. (also hplip-gui) Toolbox would 
> not execute from KDE menu or icon on panel.
> Discovered that the KDE menu points to /usr/bin/hp-toolbox, which is a link 
> to /usr/share/hplip, which does not appear to exist.
> Attempting to find hplip using Dolphin, a search from /usr/share for hplip 
> finds a folder hplip. However, opening a Dolphin window showing hidden files 
> does not reveal a folder /usr/share/hplip.

As OdyX says:

 > This is not a supported use-case

Closing.

Regards,

Brian.

Bug#990331: reportbug: cups-browsed printing fails due to apparmor config with message 'No destination host name supplied by cups-browsed for printer'

[Brian Potkin]

On Sat 11 Sep 2021 at 19:48:06 +0200, Florent Rougon wrote:

> Hello Brian,
> 
> As I wrote in my previous message, the two lines I quoted from my
> /var/log/syslog are from **before the fix** (i.e., before I purged
> cups-browsed).

My lax reading, Florent. Thanks for the correction.

Cheers,

Brian.

Bug#990331: reportbug: cups-browsed printing fails due to apparmor config with message 'No destination host name supplied by cups-browsed for printer'

[Brian Potkin]

On Sat 11 Sep 2021 at 15:48:42 +0200, Florent Rougon wrote:

> Hello,

Hello Florent,

Thank you for your contribution to this report.

> I also had the not-very-helpful message from CUPS:

The message is actually from cups-browsed.

>   No destination host name supplied by cups-browsed for printer, is
>   cups-browsed running?
> 
> Of course, cups-browsed was well running and I even tried to restart it,
> also cups.service, etc. The solution I found, before reading this
> report, was inspired by this answer:
> 
>   https://askubuntu.com/a/1128869
> 
> Here it is. First some context: the printer is connected to 
> and printing from  first worked, then failed for the *very
> same document* in the *very same Okular instance*---I simply wanted to
> print two sets of pages from the same document, oh my...
> 
> Solution (everything done on ):
> 
> 1) I purged the cups-browsed package, even though cups-daemon recommends
>it.

cups-browsed basically provides *auto-setup* of printers and print
queues. Many users apprreciate this function. But, of course, it
may be purged. I often do not use it, but would not dream of advising
other users to do the same, although, like you. I might suggest it.

> 2) Then I figured out I needed to do “Delete Printer” from the CUPS web
>administration page for the printer (otherwise, trying to do step 3
>would fail with the incomprehensible error message “Unable to add
>printer:Cannot change printer-is-shared for remote queues.”—that,
>regardless of whether “Share printer” was being checked).
> 
> 3) From the CUPS web administration page:
> 
>Administration → Add Printer → Discovered Network Printers: Brother
>DCP-L2550DN (driverless) @  (DCP-L2550DN DCP-L2550DN
>series) → ... → Add Printer (the button).
> 
> Finally, I was able to print from .
> 
> Even though this solution is quite different from that proposed by
> Gabriel, this may very well be the same issue, because now that I've
> found this report, I see that my /var/log/syslog on  from
> before the fix has entries like:

This solution involves setting up a printer manually. It is perfectly
acceptable.

> Sep 11 13:39:09 localhost kernel: [15658.624326] audit: type=1400 audit(...): 
> apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=6811 
> comm="cupsd" capability=12  capname="net_admin"

OK.

> Sep 11 13:39:09 localhost kernel: [15658.718083] audit: type=1400 audit(...): 
> apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" 
> pid=6814 comm="cups-browsed" capability=23  capname="sys_nice"

I wouldn't expect this line after cups-browsed has been purged. There
isn't an apparmor profile to use.
 
> Hope this helps other people. Regards,

It does.

-- 
Brian.

Bug#942190: cups: Memory leak for WIFI enabled printer.

[Brian Potkin]

tags 942190 moreinfo
thanks


On Fri 11 Oct 2019 at 22:00:40 +0200, Mladen Mijatov wrote:

> Package: cups
> Version: 2.3.0-5
> Severity: normal
> 
> I have HP LaserJet 1102W which I use through WIFI network. Over time cupsd
> starts leaking memory and within few hours goes to 1GB sometimes.

Thank you for your report, Mladen. Is this still an issue on Debian 11
(bullseye)?
 
> Printer requires HP's LIP service and drivers to work.

HPLIP is not required. This printer should do driverless printing.
Please see our wiki.

> I have also noticed that when printer is interrupted in half-print, even if I
> rester printing service memory will leak. Since I have never reported cups
> related issues submitting additional information would require some level of
> guidance.

Regards,

Brian.

Bug#928838: cups: Printing from local queue via remote queue not working any more, jobs just vanish

[Brian Potkin]

tags 928838 moreinfo
thanks


On Sun 12 May 2019 at 04:20:12 +0200, Robert Senger wrote:

> Package: cups
> Version: 2.2.10-6
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> Setup:
> 
> Laptop (Client) running Debian 9/10 and CUPS 2.2.1/2.2.10
> Server/Router running Debian 10 and CUPS 2.2.10
> Printer Samsung Xpress C480W, LAN/WLAN
> 
> Laptop is connected to Server via SSID WLAN_1, Subnet 1
> Printer is connected to Server via SSID WLAN_2, Subnet 2
> Server should act as a print server running CUPS. Clients (laptop, printer) in
> different subnets should not communicate directly.
> 
> Printer is configured in CUPS on the server as 
> ipp://printername:631/ipp/print,
> with Samsung C48x driver, queue name SAMSUNG, printing test pages from the
> server's web interface works fine
> Printer is configured in CUPS on the Laptop as
> ipps://servername:631/printers/SAMSUNG
> 
> With Debian 9 and CUPS 2.2.1 on the Server, this setup worked fine.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Upgraded Server to Debian 10, CUPS 2.2.10
> 
>* What was the outcome of this action?
> 
> Printing as describes above stopped working. Jobs sent from the laptop just go
> into Nirvana, they vanish and do not show up in the server's queue. The 
> servers
> access_log reports success, but printing never happens. No errors are reported
> neither on the laptop nor on the server.
> 
>* What outcome did you expect instead?
> 
> Printing as before.
> 
>* Workaround(s)
> 
> - Downgrading CUPS from 2.2.10 to 2.2.1 (debs from Debian 9) on the Debian 10
> server fixes this problem, printing works fine again.
> - Using a client.conf file with "ServerName servername" makes printing
> possible, but without a local queue there's no queue dialog that can report
> failures (emtpy tray, paper jam) on the client
> - Printing directly to the printer from the laptop works, but is not desired
> 
> So, CUPS 2.2.10 is broken when used as a print server for clients running 
> local
> queues.

Thank you for your report, Robert. Did you ever resolve this issue for
yourself? Perhaps by upgrading to bullseye on client and server?

Regards,

Brian.

Bug#712872: cups: [RFE] Modifying authentication data for a job in the queue

[Brian Potkin]

tags 712872 moreinfo
thanks



On Thu 20 Jun 2013 at 12:59:37 +0100, Sam Morris wrote:

> Package: cups
> Version: 1.6.2-9
> Severity: wishlist
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Some programs (such as Libreoffice) do not provide a way to specify a
> username and password when printing to a printer that has
> "AuthInfoRequired username,password" in its printers.conf entry.
> 
> A job created by such a program will sit in the queue until an
> administrator removes it.
> 
> I'd like a way for the administrator to specify authentication values
> for such a job that has been created without them. Something like:
> 
>   # lpmodify -o username=foo,password 7
>   Enter value for 'password': ***
> 
> Here the given value was used for username, and since no password was
> specified it was prompted so that it is not visible in the process's
> command line arguments, nor is it recorded in the user's shell history.

Hello Sam,

Michael Sweet presented some ideas. If the first one suits your
situation, I would suggest closing this rather old report.

If the second idea (involving lp and -i) is to be pursued, I would
suggest you submit an issue at

  https://github.com/OpenPrinting/cups/issues

Regards,

Brian.

Bug#931831: cups: http://localhost:631/ is served with HTTP Content-Type: text/plain

[Brian Potkin]

tags 931831 moreinfo
thanks


On Thu 11 Jul 2019 at 05:30:32 +, Witold Baryluk wrote:

> Package: cups
> Version: 2.2.10-6
> Severity: important
> 
> 
> $ curl -v http://localhost:631/
> ...
> > GET / HTTP/1.1
> > Host: localhost:631
> > User-Agent: curl/7.64.0
> > Accept: */*
> > 
> < HTTP/1.1 200 OK
> < Connection: Keep-Alive
> < Content-Language: en_US
> < Content-Length: 2364
> < Content-Type: text/plain
> < Date: Thu, 11 Jul 2019 05:27:25 GMT
> < Keep-Alive: timeout=10
> < Last-Modified: Tue, 23 Apr 2019 06:33:01 GMT
> < Accept-Encoding: gzip, deflate, identity
> < Server: CUPS/2.2 IPP/2.1
> < X-Frame-Options: DENY
> < Content-Security-Policy: frame-ancestors 'none'
> < 
> 
> 
>   
> 
> 
> 
> 
> 
> 
> Home - CUPS 2.2.10
>   
>   
> 
> ...
> 
> 
> Obviously this is not correct.
> 
> CUPS should serve it as Content-Type: text/html
> 
> Firefox and Chromium display the served data as raw text, making web
> interface unusable.

Thank you for both your reports, Witold.

With cups 2.3.3op2-6 and 2.3.3op2-7 (the present unstable version)
I get:

brian@desktop:~$ curl -sSi http://localhost:631/ | grep ^Content-Type
Content-Type: text/html; charset=utf-8
brian@desktop:~$

Please would you test with either of these versions.

Regards,

Brian.

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Brian Potkin]

On Sat 04 Sep 2021 at 16:16:50 +0200, Nader Nooryani wrote:

> Package: task-gnome-desktop
> Version: 3.68
> 
> As of Debian 11, Print Server is no longer included as an option in the
> Debian installer if you use the defaults: Debian desktop environment, GNOME
> and standard system utilities.  Ref:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950553
> 
> This leaves the user without CUPS after a default install.  This should
> perhaps be included in task-gnome-desktop
> 
> Suggestion: It may be wise to include CUPS in task-gnome-desktop or
> somewhere else, since there are no instructions informing the user how they
> can enable support for printing.
> 
> I am using Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03)
> x86_64 GNU/Linux

>From a previous mail to -boot:

 > I have written a bit more about this on Reddit as well.
 > https://www.reddit.com/r/debian/comments/pgl6c9/debian_11_and_printing/

It would be nice if the reddit thread could be updated to record the
responsive and timely intervention from the d-i maintainers.

Regards,

Brian.

Bug#976361: cups: Cups*-2.3.3op1-2 can not start

[Brian Potkin]

tags 976361 moreinfo
thanks


On Fri 04 Dec 2020 at 10:00:43 +0900, Tomoo Nomura wrote:

> Package: cups
> Version: 2.3.3op1-2
> Severity: important
> 
> Dear Maintainer,
> 
> When upgrading to 2.3.3op1-2, cups can not start with an error "Dependency 
> failed for CUPS Scheduler".
> 
> here is a log;
> 
> tom-lin@root:/etc/cups# journalctl -xe
> ░░ Defined-By: systemd
> ░░ Support: https://www.debian.org/support
> ░░
> ░░ The unit cups.socket has entered the 'failed' state with result 
> 'start-limit-hit'.
> Dec 02 19:32:29 tom-lin systemd[1]: Failed to listen on CUPS Scheduler.
> ░░ Subject: A start job for unit cups.socket has failed
> ░░ Defined-By: systemd
> ░░ Support: https://www.debian.org/support
> ░░
> ░░ A start job for unit cups.socket has finished with a failure.
> ░░
> ░░ The job identifier is 4029 and the job result is failed.
> Dec 02 19:32:29 tom-lin systemd[1]: Dependency failed for CUPS Scheduler.
> ░░ Subject: A start job for unit cups.service has failed
> ░░ Defined-By: systemd
> ░░ Support: https://www.debian.org/support
> ░░
> ░░ A start job for unit cups.service has finished with a failure.
> ░░
> ░░ The job identifier is 3927 and the job result is dependency. 
> 
> After downgrading to 2.3.3-1, it works well.

Thank you for your report, Tomoo.

What is the behaviour of 2.3.3op2-7, the present unstable version?

Regards,

Brian.