Usage? connecting CUPS to pappl printer -- what ipp:// uri to use?

[pgnd]

on

lsb_release -rd
    Description:    Fedora release 34 (Thirty Four)
    Release:        34

with

rpm -qa | egrep "cups|^hp"
    cups-2.3.3op2-7.fc34.x86_64
    cups-client-2.3.3op2-7.fc34.x86_64
    cups-filesystem-2.3.3op2-7.fc34.noarch
    cups-filters-1.28.9-2.fc34.x86_64
    cups-filters-libs-1.28.9-2.fc34.x86_64
    cups-ipptool-2.3.3op2-7.fc34.x86_64
    cups-libs-2.3.3op2-7.fc34.x86_64
    cups-printerapp-2.3.3op2-7.fc34.x86_64
    gutenprint-cups-5.3.4-4.fc34.x86_64
    hplip-3.21.2-10.fc34.x86_64
    hplip-common-3.21.2-10.fc34.x86_64
    hplip-libs-3.21.2-10.fc34.x86_64
    python3-cups-2.0.1-10.fc34.x86_64

i've installed the snap

snap list ps-printer-app
    Name            Version  Rev  Tracking     Publisher      Notes
    ps-printer-app  1.0      429  latest/edge  openprinting✓  -

the app's running

ps-printer-app status
    WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
    Running, idle since Fri, 03 Sep 2021 21:21:57 GMT

driver's availble for my printer (HPLJ 4050n),

ps-printer-app drivers | grep hp | grep 4050
    WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
    hp--laserjet-4050-series--en "HP laserjet 4050 series (en)" "MFG:Hewlett-Packard;MDL:hp laserjet 4050 series;"

in WebUI @

http://localhost:8000

I've added the printer,

ps-printer-app printers
    WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
    HPLJ_4050n_pappl

(1) In WebUI, click to send "Test Page" does connect to the printer, but triggers an endless stream of blank pages. "Cancel Job" is required to stop.

(2) I'm trying to get any app -- e.g. Firefox, Brave, Okular -- to recognize the pappl-setup printer.

IIUC (?), need to 'tell' CUPS about it: "print with CUPS, CUPS (and also cups-browsed) discover and treat the printers set up with this Printer Application as driverless IPP printers (IPP Everywhere and AirPrint)."

In CUPS webui @

http://localhost:8000

I assume (?) I need to enter an "ipp://" URI. What form must that take? To date, under "just CUPS", I've always/only used "socket://I.P.addr.ess".

[pgnd]

just noticed that the 'endless stream' of blank pages is after a single page printed,

%!PS-Adobe-3.0
    %%For: (guest)
        %%Title: (Test Page)
            %RBINumCopies: 1
                %%Pages: (atend)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% If you can read this, your printer is not a PostScript printer.        %%%%
%%%%                                                                        %%%%
%%%% Do not set it up with the PostScript Printer Application.              %%%%
%%%%                                                                        %%%%
%%%% If the PostScript Printer Application has set it up automatically,     %%%%
%%%% this is a bug. Report it here:                                         %%%%
%%%%    https:://github.com/OpenPrinting/ps-printer-app/issues              %%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The printer, an HP LJ 4050n

 https://www.cnet.com/products/hp-laserjet-4050/ 

is a Postscript-capable printer; specificially, supporting

PCL 5, PCL 6, PostScript 2 

[tillkamppeter]

On the printer you have probably some web admin interface, reachable by entering the printer's host name or IP in a web browser. You can perhaps configure there which print data formats/Page Description Languages (PDL) are actually accepted. Make sure that PostScript printing is enabled there.

Try to print a PostScript file directly to the printer, without any filtering or spooling:

nc -w1 IP_ADDRESS 9100 < /snap/ps-printer-app/current/usr/share/ps-printer-app/testpage.ps

Does it come out correctly?

Also sometimes turning off the printer and turning it on again helps.

[tillkamppeter]

In the Printer Application's web interface (http://localhost:8000/) you probably did everything correct, selecting your printer as auto-discovered from the device list and let the "driver" (exactly the model) get auto-selected.

In CUPS (http://localhost:631/) you will not need to do anything. CUPS creates a virtual print queue with the same name as the queue you defined in the Printer Application. It is correct that CUPS considers your printer a "driverless IPP" printer, "IPP Everywhere", or "AirPrint", as a Printer Application is nothing more than an emulation of a driverless IPP printer, to make non-driverless legacy printers work like driverless printers.

Also try to restart the Printer Application:

sudo snap stop ps-printer-app
sudo snap start ps-printer-app

and also assure that there are not several Printer Applications in your network using the same queue names.

Some print dialogs cannot cope with virtual CUPS queues as they use a too old API of CUPS. So these printers do not appear. Here cups-browsed helps. This utility automatically converts virtual CUPS queues into permanent CUPS queues.

[tillkamppeter]

The URI of your printer (for example for the lpadmin command of CUPS is:

ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl

You find these URIs by running

ippfind

or

driverless --std-ipp-uris

If you run

driverless

you also get CUPS URIs, but based on the DNS-SD service names, independent on the port on which your Printer Application is operating.

You can manually create a permanent CUPS queue via

lpadmin -p QUEUE_NAME -E -v URI -m everywhere

where you can freely choose the QUEUE_NAME and URI is the URI as obtained with the methods above.

[tillkamppeter]

Note: The GTK print dialog (GEdit, evince, Thunderbird, ...) will handle virtual CUPS queues in Ubuntu 21.10, to be released mid-October.

[pgnd]

@tillkamppeter

Thanks for the reply and the _very_helpful info!

On the printer you have probably some web admin interface, reachable by entering the printer's host name or IP in a web browser.

unfortunately, only the HP logo, and a blank page

You can perhaps configure there which print data formats/Page Description Languages (PDL) are actually accepted. Make sure that PostScript printing is enabled there.

In the printer's front-panel "Configuration Menu", I switched the 'Personality' setting from =PCL to =PS !

now, 'Printer Test Page' works as expected from pappl WebUI -- no more stream of blank pages.

Test page, "Printed with the OpenPrinting PostScript Printer Application" correctly reports:

Interpreter Information
    PostScript: Level 2
    Version: 2014.116 (0)
    Product: HP LaserJet 4050 Series
    Serial #: ...

Try to print a PostScript file directly to the printer, without any filtering or spooling:

testing with

nc -w1 172.28.8.101 9100 < /snap/ps-printer-app/current/usr/share/ps-printer-app/testpage.ps

works successfully, as well

In CUPS (http://localhost:631/) you will not need to do anything. CUPS creates a virtual print queue with the same name as the queue you defined in the Printer Application.

restart the Printer Application:

exec

whoami
    myuser
sudo snap stop ps-printer-app
sudo snap start ps-printer-app
ps-printer-app printers
    WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
    HPLJ_4050n_pappl

checking

driverless --std-ipp-uris
    ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl
    ipps://localhost:8000/ipp/print/HPLJ_4050n_pappl

in the CUPS:631 ui, there's NO printer listed.

should that 'virtual print queue' be seen/displayed at all in the CUPS UI?

Once I've exec'd

sudo snap start ps-printer-app

The printer queue does appear to apps -- and can be selected from print dialogs.

But, print jobs launched from THOSE print dialogs currently do nothing -- no traffic to the printer at all.

Double-checking at this point, a "Print Test Page" from the UI still works.

Not sure yet even where to look for debug info ...

Note: The GTK print dialog (GEdit, evince, Thunderbird, ...) will handle virtual CUPS queues in Ubuntu 21.10, to be released mid-October.

fwiw, I'm running snapd on Fedora 34 atm,

snap version
  snap    2.51.7-1.fc34
  snapd   2.51.7-1.fc34
  series  16
  fedora  34
  kernel  5.13.13-200.fc34.x86_64

[tillkamppeter]

That the printer has no working web interface is strange. Perhaps one can also control it by the front panel. Seems to be a security feature to prevent people not having physical access to the printer changing its configuration.

By default, printers have automatic recognition of the input data format, so an admin can have changed it.

The web interface of CUPS does not show virtual queues, unfortunately. You could post a feature request on CUPS. This would make debugging printing problems much easier.

GTK of Ubuntu 21.10 is 3.24.29 and 4.3.1. I assume 3.24.29 is used for most apps though, especially Thunderbird where I have tested. So it depends on the GTK version used in your Fedora (I did not check, but I hope the fix is upstream and not a Debian/Ubuntu-specific patch).

[pgnd]

That the printer has no working web interface is strange. Perhaps one can also control it by the front panel.

I'll poke around in there ....

So it depends on the GTK version used in your Fedora

here, for F34, it's

rpm -qa | grep -i ^gtk3
  gtk3-3.24.30-1.fc34.x86_64

is there some trace/debug info I can grab that'd be useful in debugging why I've no output to the printer using the pappl-setup queue? still possible, of course, I've missed a step ...

[pgnd]

That the printer has no working web interface is strange. Perhaps one can also control it by the front panel.

fwiw,

it appears that the webUI requires java!; challenging with a modern browser :-/

options are (1) front panel, and (2) there'a telnet interface that provides control for much of the printer config. but not all. notably, NOT the 'personality' switch between PCL <> PS.

[tillkamppeter]

To debug the virtual queue problem you could first simply try

lp -d HPLJ_4050n_pappl FILE

FILE being PostScript, PDF, JPG, or PNG.

If this prints, you have an evidence that the virtual queue is there, even if it only accepts the job (not saying that the printer does not exist) is already an evidence that the virtual queue is there. The virtal queue stays for one minute of inactivity and will be removed then. During this time you can find the queue's auto-generated PPD file, /etc/cups/ppd/HPLJ_4050n_pappl.ppd. Note that the file is only readable by root and that it is not HP's one for your printer, but a PPD file, auto-generated by CUPS, for the driverless IPP printer the Printer Application is emulating.

If you get the virtual CUPS queue but now printing, you need to switch CUPS into debug mode (cupsctl --debug-logging) and look into the /var/log/cups/error_log) file.

[pgnd]

checking

driverless --std-ipp-uris
    ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl
    ipps://localhost:8000/ipp/print/HPLJ_4050n_pappl
ps-printer-app printers
    WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
    HPLJ_4050n_pappl

enabling

cupsctl --debug-logging
grep debug /etc/cups/cupsd.conf
    LogLevel debug
systemctl restart cups
ls -al /var/log/cups/*
    ls: cannot access '/var/log/cups/*': No such file or directory

then exec of

lp -d HPLJ_4050n_pappl ./TEST.pdf

does NOT print, & eventually returns just

lp: The printer or class does not exist.

where, watching

journalctl -f grep -i cups
    ...

=====> https://pastebin.com/WrWFb7Sw

& verifying, print to NON-pappl printer/queue, i.e. my usual CUPS socket:// -> HPLJ 4050n works fine.

[tillkamppeter]

What is the output of

avahi-browse -r -t _ipps._tcp

and

avahi-browse -r -t _ipp._tcp

?

[pgnd]

not installed

avahi-browse -r -t _ipps._tcp
  bash: avahi-browse: command not found
avahi-browse -r -t _ipp._tcp
  bash: avahi-browse: command not found

rpm -qa | grep -i avahi
  avahi-libs-0.8-14.fc34.x86_64
  avahi-0.8-14.fc34.x86_64
  avahi-glib-0.8-14.fc34.x86_64

cnf avahi-browse
  bash: avahi-browse: command not found...
  Install package 'avahi-tools' to provide command 'avahi-browse'? [N/y] y

 * Waiting in queue...
The following packages have to be installed:
 avahi-tools-0.8-9.fc34.x86_64  Command line tools for mDNS browsing and publishing
The following packages have to be downgraded:
 avahi-0.8-9.fc34.x86_64        Local network service discovery
 avahi-glib-0.8-9.fc34.x86_64   Glib libraries for avahi
 avahi-libs-0.8-9.fc34.x86_64   Libraries for avahi run-time use
^C

[pgnd]

per cups docs,

https://www.cups.org/doc/network.html

mdns is an option

reading the pappl docs

https://www.msweet.org/pappl/

"Avahi 0.8 or later (except on macOS) for mDNS/DNS-SD support"

iiuc, then, if not wanting to use mdns/bonjour, then avahi* is not a required install.

or, IS it for ps-printer-app ?

although, in any case, shouldn't any such req't be filled by the snap?

[tillkamppeter]

Does this mean that Fedora has discontinued/removed avahi-tools, and with it avahi-browse? How can a sys admin live without avahi-browse? Report a bug at Fedora.

Alternatively, you can try the GUI tool avahi-discover. It opens a window and shows a list of discovered devices, sorted by network interfaces, then by device types. Look under "Internet Printer" and "Secure Internet Printer".

[tillkamppeter]

DNS-SD/mDNS is essential for driverless printing, especially if you have driverless IPP network printers. You could get away without it if you only have Printer Applications and manually create queues pointing to the printers under the Printer Applications and using -m everywhere.

But as you can see the Printer Application's printer URIs with the driverless tool you have working Avahi on your system and so you have DNS-SD/mDNS.

The Printer Applications which are available in the Snap Store (created by Michael Sweet and by me, the latter under the devloper "OpenPrinting") have DNS-SD/mDNS support via Avahi built-in. If you install them on a machine which is running avahi-daemon (like yours) the printers get registered on avahi-damon and so CUPS sees them (or at least should see them). The avahi-daemon part is working for you as the driverless utility sees your printer.

[pgnd]

Does this mean that Fedora has discontinued/removed avahi-tools, and with it avahi-browse?

No idea what Fedora project's decided :-/

How can a sys admin live without avahi-browse?

Until starting to work with pappl, I've had no particular need for it.

you can try the GUI tool avahi-discover

no such pkg in Fedora

as you point out

The avahi-daemon part is working for you as the driverless utility sees your printer.

given

DNS-SD/mDNS is essential for driverless printing

it does seem the snap-installed app's tools/env are discovering -- both with ippfind and driverless

just not printing.

so what's missing?

[pgnd]

fyi,

Does this mean that Fedora has discontinued/removed avahi-tools, and with it avahi-browse? No idea what Fedora project's decided :-/

https://src.fedoraproject.org/rpms/avahi/blob/rawhide/f/avahi.spec#_656

It's 'in there' ... why it's not in the current installed packages, I need to poke around for

[tillkamppeter]

The problem seems to be the CUPS on your system. It is not generating virtual queues for your printer. If it tries and fails it would leave appropriate traces in error_log (error messages). If it does not try, it is mis-configured or stone-old.

You can, for the time being, manually create the CUPS queue via

lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere

With this you should be able to print. But note also that with such a manual queue set up you cannot investigate whether CUPS would create a virtual queue or not as CUPS does not create virtual queues to printers already covered. You have to remove it then (and probably also to restart CUPS).

For investigation about the non-creation of the virtual queue please attach the following files:

• /etc/cups/cupsd.conf
• /etc/cups/cups-files.conf
• /var/log/cups/error_log

Note that you have to rename the copies of the files to have a .txt extension to attach them here. If you do not get a /var/log/cups/error_log try restarting CUPS, check whether perhaps your disk is full, check also /etc/cups/cupsd.confand /etc/cups/cups-files.conffor any mis-configuration.

[tillkamppeter]

@zdohnal, it looks like that we have a problem of CUPS in Fedora 34 not creating virtual queues for IPP printers advertising themselves via DNS-SD (driverless IPP printing, IPP Everywhere, AirPrint). Could you help here?

[pgnd]

should be able to print after exec of

lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere
systemctl restart cups

printer option " lj4050-pappl" does appear in apps' print dialog https://i.imgur.com/gr4hyzX.png

but, again, printing "to" it fails -- no contact/output to printer. printing via non-pappl queue (jetdirect socket://) works as usual.

For investigation about the non-creation of the virtual queue please attach the following files:

/etc/cups/cupsd.conf https://pastebin.com/x2k8drAY

/etc/cups/cups-files.conf https://pastebin.com/wRTg71Mw

/var/log/cups/error_log

ls -al /var/log/cups/error_log
ls: cannot access '/var/log/cups/error_log': No such file or directory

check whether perhaps your disk is full

nope.

df -h | grep log
  /dev/mapper/VG0-LV_VARLOG        ext4       20G  643M   18G   4% /var/log

check also /etc/cups/cupsd.confand /etc/cups/cups-files.conffor any mis-configuration.

both (as included above) should be as-installed .... staring at them now :-/

[pgnd]

fyi,

https://fedoraproject.org/wiki/How_to_debug_printing_problems#Location_of_CUPS_logging

Location of CUPS loggingCUPS logging is located in the system journal by default, but the logging into a file can be set in /etc/cups/cups-files.conf with directive 'ErrorLog'. If you want to change the default settings, then the name of the logging file is irrelevant, but it is recommended to put the file into path '/var/log/cups', otherwise SELinux will block cupsd from accessing it. 

[tillkamppeter]

OK, then we know to where CUPS is logging. So then please either consult the log there and extract it from there to attach here, or change configuration to classic error_log.

Once you have found the easier method for you to handle the CUPS log, restart CUPS at first, then restart the Printer Application and look for what happens in the CUPS log by that. If all seams normal and CUPS discovers your printer the next step is try to print to the virtual queue and look into the log to find out why CUPS does not create a virtual queue.

[tillkamppeter]

That your printer does not print even with the manually created queue looks like that CUPS is not able to talk IPP to your printer at localhost:8000. This can be investigated in the CUPS log, too.

[pgnd]

So then please either consult the log there and extract it from there to attach here

restart CUPS at first

systemctl restart cups

https://pastebin.com/aXV2LHWw

then restart the Printer Application and look for what happens in the CUPS log by that

sudo snap restart ps-printer-app

https://pastebin.com/tMJHsm9g

and there's a segfault!

Sep 03 18:56:39 test.loc kernel: ps-printer-app[39379]: segfault at 0 ip 00007fa02e682b02 sp 00007ffe5ab3b8d0 error 4 in libcups.so.2[7fa02e67e000+47000]

here,

locate libcups.so.2
 /usr/lib64/libcups.so.2
 /var/lib/snapd/snap/gnome-3-28-1804/145/usr/lib/x86_64-linux-gnu/libcups.so.2
 /var/lib/snapd/snap/gnome-3-28-1804/161/usr/lib/x86_64-linux-gnu/libcups.so.2
 /var/lib/snapd/snap/gnome-3-34-1804/66/usr/lib/x86_64-linux-gnu/libcups.so.2
 /var/lib/snapd/snap/gnome-3-34-1804/72/usr/lib/x86_64-linux-gnu/libcups.so.2
 /var/lib/snapd/snap/ps-printer-app/429/usr/lib/libcups.so.2

[pgnd]

and there's a segfault!

testing, it's reproducible @ each snap restart ps-printer-app

as well as on several (similarly configured) machines

[tillkamppeter]

Could you do

sudo snap stop ps-printer-app
sudo snap start ps-printer-app

Are you able to get the Printer Application started again this way?

[pgnd]

It's not that it's NOT restarting ... it is:

(1) ps ax | grep ps-printer-app
     5230 ?        Ssl    0:00 /snap/ps-printer-app/432/usr/bin/ps-printer-app -o log-level=debug -o log-file=/var/snap/ps-printer-app/common/ps-printer-app.log server
    24984 ?        Sl     0:01 /snap/ps-printer-app/429/usr/bin/ps-printer-app server -o private-server=true

sudo snap restart ps-printer-app
    Restarted.

journalctl -f | egrep -i "cups|printer"

    Sep 04 11:05:49 test.loc systemd[1]: Stopping Service for snap application ps-printer-app.ps-printer-app-server...
    Sep 04 11:05:49 test.loc kernel: ps-printer-app[5230]: segfault at 0 ip 00007f2bc6cf3b02 sp 00007ffcff306e80 error 4 in libcups.so.2[7f2bc6cef000+47000]
    Sep 04 11:05:49 test.loc kernel: CPU: 2 PID: 5230 Comm: ps-printer-app Tainted: P        W  OE     5.13.13-200.fc34.x86_64 #1
    Sep 04 11:05:49 test.loc systemd[1]: snap.ps-printer-app.ps-printer-app-server.service: Main process exited, code=killed, status=11/SEGV
    ...

ps ax | grep ps-printer-app
    24984 ?        Sl     0:01 /snap/ps-printer-app/429/usr/bin/ps-printer-app server -o private-server=true
    26195 ?        Ssl    0:00 /snap/ps-printer-app/432/usr/bin/ps-printer-app -o log-level=debug -o log-file=/var/snap/ps-printer-app/common/ps-printer-app.log server

(2) ps ax | grep ps-printer-app
    24984 ?        Sl     0:01 /snap/ps-printer-app/429/usr/bin/ps-printer-app server -o private-server=true
    26195 ?        Ssl    0:00 /snap/ps-printer-app/432/usr/bin/ps-printer-app -o log-level=debug -o log-file=/var/snap/ps-printer-app/common/ps-printer-app.log server

sudo snap stop ps-printer-app
    Stopped.

journalctl -f | egrep -i "cups|printer"

    Sep 04 11:07:59 test.loc systemd[1]: Stopping Service for snap application ps-printer-app.ps-printer-app-server...
    Sep 04 11:07:59 test.loc kernel: ps-printer-app[26195]: segfault at 0 ip 00007fd555e98b02 sp 00007ffd8a2b2250 error 4 in libcups.so.2[7fd555e94000+47000]
    Sep 04 11:07:59 test.loc kernel: CPU: 9 PID: 26195 Comm: ps-printer-app Tainted: P        W  OE     5.13.13-200.fc34.x86_64 #1
    Sep 04 11:07:59 test.loc systemd[1]: snap.ps-printer-app.ps-printer-app-server.service: Main process exited, code=killed, status=11/SEGV
    ...

sudo snap start ps-printer-app
    Started.

journalctl -f | egrep -i "cups|printer"
    ... NO SEGAULT ...

ps ax | grep ps-printer-app
    24984 ?        Sl     0:01 /snap/ps-printer-app/429/usr/bin/ps-printer-app server -o private-server=true
    26362 ?        Ssl    0:00 /snap/ps-printer-app/432/usr/bin/ps-printer-app -o log-level=debug -o log-file=/var/snap/ps-printer-app/common/ps-printer-app.log server

[zdohnal]

Hi all,

@pgnd it would be great if you provided the following information:

• what is the output of 'avahi-browse -avrt' command? (it is in avahi-tools rpm, and it is not installed by default since probably no package requires it - it is a common case about tools. Downgrading avahi during installation of avahi-tools is strange, since avahi-tools has this NVR, so there shouldn't be a downgrade - but that's a question for PackageKit which does this prompt 'your package isn't installed, do you want to install it?' - I rather prefer dnf)
• are you able to ping any .local address? You can take an address from the previous avahi-browse output

From CUPS log (though it is a grep of journalctl on 'cups', so cups-browsed from cups-filters is there too - see the link you've already shared, you can get CUPS log by journalctl -u cups) I see even cups-browsed isn't able to communicate with device created by ps-printer-app:

Sep 03 18:51:26 test.loc cups-browsed[52834]: Fri Sep  3 18:51:26 2021 get-printer-attributes: Cannot connect to printer with URI ipp://test.local:8000/ipp/print/HPLJ_4050n_pappl.
Sep 03 18:51:26 test.loc cups-browsed[52834]: Fri Sep  3 18:51:26 2021
Sep 03 18:51:26 test.loc cups-browsed[52834]: Fri Sep  3 18:51:26 2021 get-printer-attributes IPP call failed on printer HPLJ_4050n_pappl (ipp://HPLJ_4050n_pappl._ipp._tcp.local/).
Sep 03 18:51:26 test.loc cups-browsed[52834]: Fri Sep  3 18:51:26 2021 ERROR: Unable to create print queue, ignoring printer.

If my guess is correct, the core of the issue is you cannot resolve .local adress (which can be verified by the second point in the paragraph where I request more info). The current situation about .local address resolving in Fedora is that you can choose from two resolvers, both seem to work with Avahi:

1) nss-mdns - this package is a weak dependency of CUPS in Fedora, so you should get it automatically with CUPS unless you'd configured dnf to do not install weak deps. If you have nss-mdns installed and still cannot ping .local address, then inspect your /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf. If you want to modify those files, the way of how and what modify depends on whether /etc/nsswitch.conf is a symlink or not - if it is a symlink, modify only the files in /etc/authselect dir and then use authselect commands to update. If your /etc/nsswitch.conf is still a regular file (IIRC sometime around 2017-2018 authselect has started to take care of nsswitch.conf and turned it into symlink, but machines from before that time still has nsswitch.conf as a regular file), modify it directly.

2) systemd-resolved: since F33 resolved is running by default, but it doesn't take care of mDNS resolving unless you set it to. To enable resolving via resolved, you will need to set MulticastDNS=resolve in /etc/systemd/resolved.conf and then enable mdns and llmnr on the NM connection you are using.

[pgnd]

@zdohnal

afer recent upgrades, up-to-date avahi-browse@avahi-tools pkg is installed,

which avahi-browse
    /usr/bin/avahi-browse

rpm -q --whatprovides /usr/bin/avahi-browse
    avahi-tools-0.8-14.fc34.x86_64

rpm -qa | grep avahi | sort
    avahi-0.8-14.fc34.x86_64
    avahi-glib-0.8-14.fc34.x86_64
    avahi-libs-0.8-14.fc34.x86_64
    avahi-tools-0.8-14.fc34.x86_64

returns

avahi-browse -avrt
    Server version: avahi 0.8; Host name: dev.local
    E Ifce Prot Name                                          Type                 Domain
    : Cache exhausted
    : All for now

ping @.local

ping dev.local
    ping: dev.local: Name or service not known

my machine is

hostname
    dev.mylandomain.com

resolveable on my LAN, @ my local DNS

dig A dev.mylandomain.com

    ; <<>> DiG 9.16.20-RH <<>> A dev.mylandomain.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40321
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ; COOKIE: 58670dc726bfc8de010000006135f71eaf617e27d5aa17a2 (good)
    ;; QUESTION SECTION:
    ;dev.mylandomain.com.  IN      A

    ;; ANSWER SECTION:
    dev.mylandomain.com. 5 IN      A       172.28.10.7

    ;; Query time: 0 msec
    ;; SERVER: fd72:28:10::100#53(fd72:28:10::100)
    ;; WHEN: Mon Sep 06 07:10:13 EDT 2021
    ;; MSG SIZE  rcvd: 101

is pingable

ping -6 dev.mylandomain.com -c 1
    PING dev.mylandomain.com(dev.mylandomain.com (fd72:28:10::7)) 56 data bytes
    64 bytes from dev.mylandomain.com (fd72:28:10::7): icmp_seq=1 ttl=64 time=0.031 ms

    --- dev.mylandomain.com ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.031/0.031/0.031/0.000 ms

ping -4 dev.mylandomain.com -c 1
    PING  (172.28.10.7) 56(84) bytes of data.
    64 bytes from dev.mylandomain.com (172.28.10.7): icmp_seq=1 ttl=64 time=0.023 ms

    ---  ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.023/0.023/0.023/0.000 ms

as is my printer

host 172.28.10.10
    10.11.30.172.in-addr.arpa domain name pointer printer.mylandomain.com.

ping -4 172.28.10.10 -c1
    PING 172.28.10.10 (172.28.10.10) 56(84) bytes of data.
    64 bytes from 172.28.10.10: icmp_seq=1 ttl=60 time=1.37 ms

    --- 172.28.10.10 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 1.368/1.368/1.368/0.000 ms

The current situation about .local address resolving in Fedora is that you can choose from two resolvers, both seem to work with Avahi:

systemd-resolved

not in use here,

systemctl status systemd-resolved
○ systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

nss-mdns

installed

rpm -qa nss-mdns
    nss-mdns-0.14.1-11.fc34.x86_64

If you have nss-mdns installed and still cannot ping .local address, then inspect your /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf.

i do not setup/use mdns/bonjour/avahi on my LAN

resolution on my LAN is, as above, restricted to use at my local nameserver

named -v
    BIND 9.16.20-RH (Extended Support Version) <id:26db37f>

ls -al /etc/resolv.conf
    -rw-r--r-- 1 root root 125 Aug 14 07:36 /etc/resolv.conf

cat /etc/resolv.conf
    nameserver fd72:28:10::100
    nameserver 172.28.10.100
    search mylandomain.com

ls -al /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf
    -rw-r--r-- 1 root root 1.7K Aug  8 07:01 /etc/nsswitch.conf
    -rw-r--r-- 1 root root 2.3K Aug  8 07:01 /etc/authselect/user-nsswitch.conf

grep ^hosts /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf
    /etc/nsswitch.conf:hosts: dns files [NOTFOUND=return] myhostname
    /etc/authselect/user-nsswitch.conf:hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

authselect list
    - minimal        Local users only for minimal installations
    - nis            Enable NIS for system authentication
    - sssd           Enable SSSD for system authentication (also for local users only)
    - winbind        Enable winbind for system authentication
authselect current
    No existing configuration detected.

modify it directly.

to what, & where?

sounds like pappl/ps-printer-app requires mdns .local resolution, unlike CUPS itself ?

instead of changing my LAN's existing, fuinctional resolution policy/function, can pappl etc config be appropriately spec'd/changed to explicit use hostname resolution as it exists on my lan?

[tillkamppeter]

@pgnd I have fixed the segfault you are observing with the Printer Application Snaps in all of them. So please make sure you have the current versions. The Snap Store has already built all the three for the amd64 architecture and should do the updates on your system automatically. The "Rev" in snap list must be 441 for ps-printer-app, 13 for hplip-printer-app, and 31 for ghostscript-printer-app.

For your printer either ps-printer-app or hplip-printer-app should provide the support.

[pgnd]

I have fixed the segfault you are observing with the Printer Application Snaps in all of them

@tillkamppeter

Thx, will update & test in a bit ...

In general, I'm finding that the variety of older HP workhorse printers here -- PS v2 capable -- CUPS printing functions well with either PS or PCL pdl. But with PS, after send to the printer's RAM, there's a significnat processing delay -- at the printer. I'm assuming (still poking around) it's due to some combination of decompression, PS drivers lacking access to full RAM, etc. OTOH, Ghostscript PCL6 drivers seem to working really well, where, IIUC, the rasterization occurs (?) locally, before send to the printer. Seems to be handling single & multiple jobs with much less trouble.

So, atm, GS/PCL is preferable, when the choice is available.

Not yet sure what options for pappl for GS/PCL support exist; reading @ OpenPrinting now ...

EDIT: looks like this, https://github.com/OpenPrinting/ghostscript-printer-app

[tillkamppeter]

To get PCL drivers (PCL 6/XL, 5c/e) use the Ghostscript Printer Application instead of the PostScript Printer Application. There are generic entries if your printer is not explicitly listed. If you printer is HP, use the HPLIP Printer Application for non-PostScript printing.

[pgnd]

If you printer is HP, use the HPLIP Printer Application for non-PostScript printing.

thought the pappl "hp-printer-app" was just a demo app -- didn't realize it was functional. the standard HPLIP pkgs, at least those for my F34 installs, provide only a pcl3 implementation. The test printer I'm working on atm, an HP LJ 4050, supports PS, PCL5 & PCL6 pdls.

I leaned to the GS drivers for the PCL6 vs PCL3 support, (ref: https://developers.hp.com/hp-printer-command-languages-pcl, https://developers.hp.com/hp-pcl-specifications/doc/differences-between-pcl56-and-pcl3), and to be (more) free of proprietary HP drivers. And yes, both are not yet quite well informed choices ...

[pgnd]

aha,

hp-printer-app != hplip-printer app ...

[tillkamppeter]

The PCL printer support in HPLIP is not proprietary, only a few non-PCL-non-PS laser printers use HP's proprietary plugin (which is not yet supported in the HPLIP Printer Application).

[pgnd]

installed the app, and created a pappl printer

    snap list | grep printer-app
        hplip-printer-app      1.0                         13     latest/edge    openprinting*  -

    hplip-printer-app printers
        WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
        HPLJ_4050n_pappl

    hplip-printer-app status
        WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
        Running, idle since Mon, 06 Sep 2021 21:37:13 GMT

created a cups printer connected to the pappl printer instance,

    Queue Name      Description     Location        Make and Model Status
    HPLJ_4050n_ipp  HPLJ_4050n_ipp  HPLJ_4050n_ipp  LaserJet 4050 Series pcl3, hpcups 3.21.8 - IPP Everywhere

    grep -i ipp /etc/cups/ppd/HPLJ_4050n_ipp.ppd
        *PCFileName: "ippeve.ppd"
        *NickName: "LaserJet 4050 Series pcl3, hpcups 3.21.8 - IPP Everywhere"
        *ShortNickName: "LaserJet 4050 Series pcl3, hpcups 3.21.8 - IPP Everywhere"

    ls -al /etc/cups/ppd/*ipp*
        -rw-r----- 1 root lp 11K Sep  6 12:36 /etc/cups/ppd/HPLJ_4050n_ipp.ppd
        -rw-r----- 1 root lp 11K Sep  6 12:36 /etc/cups/ppd/HPLJ_4050n_ipp.ppd.O

in any give app's Print dialog, I see & can select

    HPLJ_4050n_ipp

when I Print to it, however, again, no printout/activity at the printer

for that, log shows

--> https://pastebin.com/wdb55Pyg

no more segfault afaict

[tillkamppeter]

Unfortunately, your error_log does not help much.

Please print a job and provide the error_log beginning from the first occurrence of [Job XXX] entries. XXX is the job number which you get as naswer to the lp command when printing from the command line or in the job list of lpstat -o. The beginning of the job logging is important, not the infinite loop which starts with any communication failure.

Also do not provide your file via commercial third-party services like Pastebin, as they are full of ads and the files will also expire after a certain time and so this bug report gets unusable for later reference.

Instead, copy your error_log into a file in your home directory, rename it to have a .txt file name extension (like error_log.txt) and then attach it to this bug report (to the comment with which you answer).

[pgnd]

for this setup,

where,

        HPLJ_4050n_ipp
        HPLJ_4050n_ipp (Processing, Accepting Jobs, Not Shared)
        Description:    HPLJ_4050n_ipp
        Location:   HPLJ_4050n_ipp
        Driver: LaserJet 4050 Series pcl3, hpcups 3.21.8 - IPP Everywhere (grayscale, 2-sided printing)
---->   Connection: ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl
        Defaults:   job-sheets=none, none media=na_letter_8.5x11in sides=one-sided

on failed, no-output, print to ipp-everywhere instance,

lp dummy.pdf -d HPLJ_4050n_ipp

error_log

logs1.txt

[zdohnal]

avahi-browse -avrt
  Server version: avahi 0.8; Host name: dev.local
  E Ifce Prot Name                                          Type                 Domain
  : Cache exhausted
  : All for now

ping dev.local
  ping: dev.local: Name or service not known

Ok, that explains a lot :) .

resolution on my LAN is, as above, restricted to use at my local nameserver

ls -al /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf
  -rw-r--r-- 1 root root 1.7K Aug  8 07:01 /etc/nsswitch.conf
  -rw-r--r-- 1 root root 2.3K Aug  8 07:01 /etc/authselect/user-nsswitch.conf

grep ^hosts /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf
  /etc/nsswitch.conf:hosts: dns files [NOTFOUND=return] myhostname
  /etc/authselect/user-nsswitch.conf:hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

modify it directly.

to what, & where?

Ok, then you have nsswitch.conf as a regular file, so any changes you make should go directly to it - the relevant directive is 'hosts:' which you found out it differs in /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf.

First, I would try changing 'hosts:' line in /etc/nsswitch.conf to look the same as 'hosts:' line in /etc/authselect/user-nsswitch.conf, (here maybe restart can be needed, I'm not sure whether services pick up nsswitch.conf changes without some 'restart') and try pinging a .local address. If the previous didn't help, you can try 'hosts:' line sequence from here - it worked for the user and I have the same configuration, which works for me.

sounds like pappl/ps-printer-app requires mdns .local resolution, unlike CUPS itself ?

No, actually CUPS uses the same .local resolution as printer applications - CUPS uses it during automatic creation of 'virtual' queues (the exact term is CUPS temporary queue) when you are about to print. The tech saves an user's work on installing printer and memory on his machine, because the queue is removed after successful printing. You can overcome mdns resolution requirement by installing the print queue manually, using non-.local hostname and 'everywhere' model, but this requires your input ( so no zero configuration anymore :) ) and makes the queue permanent, so permanently reserving some of your resources. I'm glad the queues shared from printer apps can be installed the same way - it is a relief for users which don't trust their LANs...

instead of changing my LAN's existing, fuinctional resolution policy/function, can pappl etc config be appropriately spec'd/changed to explicit use hostname resolution as it exists on my lan?

IIUC the problem with using classic hostname is that it is not shared in mDNS messages, so applications aren't able to find the info about it. Probably they could do some reverse DNS lookups to find it out from IP, which is in the message, but it is quite an overhead when .local resolving should work out of the box.

The problem here is the nss-mdns maintainer in Fedora either no longer thinks there are people with /etc/nsswitch.conf as a regular file (authselect celebrated 4 years in Fedora this August, and that's when /etc/nsswitch.conf turned into symlink on new machines - 4 years ago), so he doesn't take care of them in spec file (nss-mdns needs to update 'some' - /etc/nsswitch.conf or /etc/authselect/user-nsswitch.conf - nsswitch.conf's hosts: line to make it work) or update RPM scriptlet failed for your configuration. Either way it would be great if you reported your issue in bugzilla for Fedora.

What I would recommend is to migrate your nsswitch.conf to authselect completely - you will get automatically changes from the system and you will prevent errors about someone forgets that nsswitch.conf can be a regular file. But as I'm not authselect maintainer, I don't know about any migration guide :( - if I were you, I would file a bug in bugzilla or asked on Fedora devel list.

As I wrote above, I'm not authselect maintainer, so those pieces of advice about nsswitch.conf changes and intentions can be inaccurate, but I told you what I found out during debugging similar issues.

[pgnd]

@zdohnal

First, I would try changing 'hosts:' line in /etc/nsswitch.conf to look the same as 'hosts:' line in /etc/authselect/user-nsswitch.conf

I'm inclined to keep my non-symlnk'd setup; need to consider it a bit more.

to be clear, then, pappl's depending on /etc/nssswitch.conf -- through services -- not explcitly on /etc/authselect/user-nsswitch.conf, correct?

You can overcome mdns resolution requirement by installing the print queue manually, using non-.local hostname and 'everywhere' model, but this requires your input ( so no zero configuration anymore :) ) and makes the queue permanent, so permanently reserving some of your resources.

This is the approach I'd prefer to take ... now to figure out the pieces to see if I can get it to work.

No, actually CUPS uses the same .local resolution as printer applications

I'm misunderstanding something on this.

Apparently, due to my current nssswitch config, '.local' resolution hasn't been allowing pappl+printer-app to function correctly

If 'CUPS uses the same .local resolution', how/why is CUPS printing here functional? Clearly something is sufficient here ... just want to get a handle on the specific difference(s).

The problem here is ... ... it would be great if you reported your issue in bugzilla for Fedora.

The assumption that mdns is/will not disabled sounds like it's the fundamental issue here.

Particularly for Zero-Trust policy, but in general as well, it's a bad assumption -- neither mandated nor recommended. Simply available as an option. Personally, I'd question that it should be a default ... but that's a different discussion.

[tillkamppeter]

Both CUPS and (PAPPL-based) Printer Applications are emulators of (driverless) IPP network printers. As they both orginate from the creator of all these standards, Michael Sweet, they probably even better fulfill the standards than most physical network printers.

One part of the standards is that a driverless IPP printer advertises itself via DNS-SD and provides a hostname by itself, using ZeroConf. On operating systems in their standard configuration (supporting DNS-SD and ZeroConf) they are supposed to get easily discovered, automatically set up and "just work".

But this also means that if your system does not support things like DNS-SD and/or ZeroConf, that the automatic setup will not necessarily work and you need to do manual steps.

First, the ZeroConf/DNS-SD support of CUPS is not needed if you only want to print locally with your CUPS queues, it is only needed that your CUPS queues get auto-discovered by remote clients if you share them.

The safest way to print with CUPS to the Printer Application should be to manually create the queue, if CUPS and the Printer Application are on the same machine, with "localhost" as host name and the port (usually 8000) of the Printer Application, like:

lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere

If the Printer Application is running on another machine, you need to use that machines IP (or the name assigned in your DNS) instead of "localhost".

With this, CUPS should not need any DNS-SD/Avah/Zeroconf, as it has an exact address to access the Printer Application. If this dooes not work, it seems to be some problem with your specific network configurartion or with Fedora, where probably @zdohnal is of more help than me.

Make also sure that there is no system-internal firewall or similar which blocks communication via port 8000.

[pgnd]

you need to do manual steps. ... The safest way to print with CUPS to the Printer Application should be to manually create the queue, if CUPS and the Printer Application are on the same machine

here, atm, they are

with "localhost" as host name and the port (usually 8000) of the Printer Application, like: lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere

Make also sure that there is no system-internal firewall or similar which blocks communication via port 8000.

there isn't

    telnet localhost 8000
        Trying 127.0.0.1...
        Connected to localhost.
        Escape character is '^]'.

with no mdns specified to be used,

    grep ^hosts /etc/nsswitch.conf
        hosts:       dns files [NOTFOUND=return] myhostname

and services disabled, as usual here,

    systemctl status -ln0 avahi-daemon cups-browsed
        ○ avahi-daemon.service - Avahi mDNS/DNS-SD Stack
             Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; disabled; vendor preset: enabled)
             Active: inactive (dead)
        TriggeredBy: ○ avahi-daemon.socket

        ○ cups-browsed.service - Make remote CUPS printers available locally
             Loaded: loaded (/usr/lib/systemd/system/cups-browsed.service; disabled; vendor preset: disabled)
             Active: inactive (dead)

'plain' CUPS printing to a local CUPS queue

@   http://localhost:631/printers/HPLJ_4050n_pcl6_hp_gutenprint

        HPLJ_4050n_pcl6_hp_gutenprint
        HPLJ_4050n_pcl6_hp_gutenprint (Idle, Accepting Jobs, Not Shared, Server Default)
        Description:    HPLJ_4050n_pcl6_hp_gutenprint
        Location:   HPLJ_4050n_pcl6_hp_gutenprint
        Driver: HP LaserJet 4050 - CUPS+Gutenprint v5.3.4 (grayscale, 2-sided printing)
        Connection: socket://172.28.10.10:9100
        Defaults:   job-sheets=none, none media=na_letter_8.5x11in sides=one-sided

works as expected

setup & create pappl instance

@ http://localhost:8000/HPLJ_4050n_pappl

        Status
        HP LaserJet 4050 Series pcl3, hpcups 3.21.8

    hplip-printer-app printers
        WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
        HPLJ_4050n_pappl

manually create permanent queue,

    lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere

    ls -al /etc/cups/ppd/lj4050-pappl.ppd
        -rw-r----- 1 root lp 11K Sep  7 08:02 /etc/cups/ppd/lj4050-pappl.ppd

    grep HPLJ_4050n_pappl /etc/cups/ppd/lj4050-pappl.ppd
        *APSupplies: "http://localhost:8000/HPLJ_4050n_pappl/"

print dialog in any app does display 'lj4050-pappl'

print "to" 'lj4050-pappl' fails as before -- no output, no connection

If this dooes not work, it seems to be some problem with your specific network configurartion or with Fedora, where probably @zdohnal is of more help than me.

ping @zdohnal

[zdohnal]

@pgnd If the situation is the same as presented in the log from https://github.com/OpenPrinting/ps-printer-app/issues/9#issuecomment-913806631 , then I beg to differ that there is no connection - CUPS connected to the virtual printer advertised by hplip-printer-app on localhost:8000, got its attributes, validated the job, created job and send the document to it. In the end it asks for printer and job attributes which show the virtual printer is stopped - imho it doesn't look like a connection issue, but rather some error happened in hplip-printer-app.

@tillkamppeter is there a way how to get debug logs from hplip-printer-app?

Edit: Ok, I see the log has log from pappl too, but I'm not sure how @pgnd got it... I see from the log:

E [2021-09-06T18:25:45.185Z] [Device] Unsupported device URI scheme \'socket\'. E [2021-09-06T18:25:45.185Z] [Printer HPLJ_4050n_pappl] Unable to open device 'socket://172.28.10.10/', pausing queue until printer becomes available.

So pappl doesn't support socket scheme here - do snaps carry their own pappl or classic installed package is used when hplip-printer-app is in the game?

[pgnd]

I beg to differ that there is no connection

My point is simply that there is no actual ouptut to the HP printer itself. And that there's no indication of any connection or traffic at the printer's control/status panel.

As you point out, there is some connection attempt to the app

I see the log has log from pappl too, but I'm not sure how @pgnd got it

DL'd from the pappl UI's 'logs' page, @

https://localhost:8000/logs

[tillkamppeter]

I assume that you are using Printer Applications installed as a Snap from the Snap Store. In this case they should not log to syslog but have their own log file:

• ps-printer-app: /var/snap/ps-printer-app/common/ps-printer-app.log
• hplip-printer-app: /var/snap/hplip-printer-app/common/hplip-printer-app.log

Printer Applications save their setup in the same directories, their state files:

• ps-printer-app: /var/snap/ps-printer-app/common/ps-printer-app.state
• hplip-printer-app: /var/snap/hplip-printer-app/common/hplip-printer-app.state

There you can see, which URI, which device ID, option defaults, ... got saved for the print queue inside the Printer Application.

If you run Printer Applications without using a Snap, like compiling right out of the source code with a simple make; sudo make install, the state file goes to /var/lib/ps-printer-app (for PostScript Printer Application, otherwise with appropriate name of your Printer Application). I am not sure how PAPPL is exactly coded but possible that logging goes to syslog if not specifying a log file.

Also if you run Printer Applications without them being in a Snap, they possibly see all the PPDs, CUPS filters, and CUPS backends installed on your system and possibly therefore show you options under "Add Printer" (devices or drivers/models) which actually do not work with this Printer Application.

As you see PAPPL logging in your syslog I suspect that you are running Printer Applications without using their Snap incarnation.

URI schemes do not only exist in CUPS but also in Printer Applications. PAPPL has some internal backends, for USB, for network with DNS-SD discovery and for network with SNMP discovery. Depending on how you connect your printer, you can see it up to three times under the "Devices" ("Add Printer" web interface page) of most Printer Applications (the ones actually using PAPPL's backends, like the PostScript Printer Application or the Ghostscript Printer Application).

Each backend in PAPPL has a scheme, socket is for SNMP-discovered network printers.

What can have happened is that you started with the PostScript Printer Application, set up your printer and later you started the HPLIP Printer Application and it somehow grabbed the state file of the PostScript Printer Application (I did not know that this can happen). The HPLIP Printer Application does not use PAPPL's built-in backends, but the CUPS backend of HPLIP instead, and therefore it does not support the socket scheme.

If you use a Printer Application, make sure you cxreate your print queue in that Printer Application, not in another one.

[tillkamppeter]

One other thing: I remembered now that under the "Devices" on the "Add Printer" page there are not only the results of the auto-discovery but there is always the last item being "Network Printer". Selecting this ungrays "Hostname/IP address". If you continue then entering a host name or IP address and the completing the form, it seems that a queue with socket scheme is created, regardless whether PAPPL's socket backend is perhaps disabled in a certain Printer Application. This is a bug in PAPPL.

I did not find a solution yet to suppress this item in the web interface. So please only use the auto-discovery results in the HPLIP Printer Application. AFAIR HPLIP uses SNMP or SLC to discover network printers by default, so your printer should appear even without running Avahi daemon.

[pgnd]

I assume that you are using Printer Applications installed as a Snap from the Snap Store

yes

snap install hplip-printer-app --edge
snap list hplip-printer-app
    Name               Version  Rev  Tracking     Publisher      Notes
    hplip-printer-app  1.0      16   latest/edge  openprinting✓  -

In this case they should not log to syslog but have their own log file: ... Printer Applications save their setup in the same directories, their state files:

here,

ls -al \
 /var/snap/hplip-printer-app/common/hplip-printer-app.state \
 /var/snap/ps-printer-app/common/ps-printer-app.log \
 /var/snap/hplip-printer-app/common/hplip-printer-app.log \
 /var/snap/ps-printer-app/common/ps-printer-app.state

    ls: cannot access '/var/snap/ps-printer-app/common/ps-printer-app.log': No such file or directory
    ls: cannot access '/var/snap/ps-printer-app/common/ps-printer-app.state': No such file or directory
    -rw------- 1 root root 508K Sep  8 04:41 /var/snap/hplip-printer-app/common/hplip-printer-app.log
    -rw-r--r-- 1 root root 5.1K Sep  7 12:20 /var/snap/hplip-printer-app/common/hplip-printer-app.state

As you see PAPPL logging in your syslog I suspect that you are running Printer Applications without using their Snap incarnation.

I'm not sure what that means :-/

I've only installed the Printer App via snap.

What can have happened is that you started with the PostScript Printer Application, set up your printer and later you started the HPLIP Printer Application and it somehow grabbed the state file of the PostScript Printer Application (I did not know that this can happen).

there's only one instance here

find /var/snap -type d -name '*printer*'
    /var/snap/hplip-printer-app

find /var/snap -type f -name '*state'
    /var/snap/hplip-printer-app/common/hplip-printer-app.state

The HPLIP Printer Application does not use PAPPL's built-in backends, but the CUPS backend of HPLIP instead, and therefore it does not support the socket scheme.

I'm not sure what to do with that.

CUPS itself certainly supports the socket:// scheme.

The HP printer's got a JetDirect network card, directly accessible via socet:// -- that's how I've always connected. CUPS printing via socket:// is fine.

[tillkamppeter]

See my last comment. Probably you used this option to manually enter the IP which does not work in the HPLIP Printer Application.

[pgnd]

I remembered now that under the "Devices" on the "Add Printer" page there are not only the results of the auto-discovery but there is always the last item being "Network Printer".

on the hplip-printer-app's "Add Printer" web page, there's no list of Auto-Discovered options: