repeat of previous question that has gone unanswered several times.

[gene heskett]

Greetings all;

I have a mixed home network, some buster, some bullseye, all up to date
a/o yesterday.

I have 2 printers shared on this bullseye main box, available as 5 or 6
printers, each configured in cups to do a specific job. Good printers,
both running on brother's own linux drivers for that printer.

All my buster machines can use both of these printers just as if they
were plugged into that machine, but a machine shop full of sawdust and
metal shavings is not a good printer environment, even if there was room
for them, which there isn't.

All of my bullseye machines are locked out, printer screen at
localhost:631 is empty, and no printers can be found and added.

But open a shell, and type "lpstat -t" and it gets the full list of
available printers on that same bullseye machine whose cups output is empty.

Why?

Thank you for any insight.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[Lee]

On 4/30/23, gene heskett <ghes...@shentel.net> wrote:
> Greetings all;
>
> I have a mixed home network, some buster, some bullseye, all up to date
> a/o yesterday.
>
> I have 2 printers shared on this bullseye main box, available as 5 or 6
> printers, each configured in cups to do a specific job. Good printers,
> both running on brother's own linux drivers for that printer.
>
> All my buster machines can use both of these printers just as if they
> were plugged into that machine, but a machine shop full of sawdust and
> metal shavings is not a good printer environment, even if there was room
> for them, which there isn't.
>
> All of my bullseye machines are locked out, printer screen at
> localhost:631 is empty, and no printers can be found and added.
>
> But open a shell, and type "lpstat -t" and it gets the full list of
> available printers on that same bullseye machine whose cups output is
> empty.
>
> Why?

Take a look at
https://wiki.debian.org/CUPSQuickPrintQueues

The quick ref is to install avahi-utils and run
avahi-browse -rt _ipp._tcp | grep URF

If you get a line matching URF the printer supports the AirPrint
service. Install cups and see if it works (which is all that I needed
to do to get the printer working). If no, what does

avahi-browse -rt _ipp._tcp

and

systemctl status avahi-daemon

show you?

Regards,
Lee

[David Wright]

On Sun 30 Apr 2023 at 19:05:21 (-0400), gene heskett wrote:
>
> I have a mixed home network, some buster, some bullseye, all up to
> date a/o yesterday.
>
> I have 2 printers shared on this bullseye main box, available as 5 or
> 6 printers, each configured in cups to do a specific job. Good
> printers, both running on brother's own linux drivers for that
> printer.
>
> All my buster machines can use both of these printers just as if they
> were plugged into that machine, but a machine shop full of sawdust and
> metal shavings is not a good printer environment, even if there was
> room for them, which there isn't.
>
> All of my bullseye machines are locked out, printer screen at
> localhost:631 is empty, and no printers can be found and added.
>
> But open a shell, and type "lpstat -t" and it gets the full list of
> available printers on that same bullseye machine whose cups output is
> empty.

I thought you had uninstalled cups-browsed from the bullseye machines.
Are the printers that you can't see actually on the network, or are
they connected to a specific machine (I didn't understand their being
"shared"). It was worrying that you said that one machine worked when
using the IP address but not its FQDN. (Actually, I've always thought
it misguided that that host, coyote, has the same name as the network.)

Cheers,
David.

[gene heskett]

On 4/30/23 20:19, Lee wrote:
> On 4/30/23, gene heskett <ghes...@shentel.net> wrote:
>> Greetings all;
>>
>> I have a mixed home network, some buster, some bullseye, all up to date
>> a/o yesterday.
>>
>> I have 2 printers shared on this bullseye main box, available as 5 or 6
>> printers, each configured in cups to do a specific job. Good printers,
>> both running on brother's own linux drivers for that printer.
>>
>> All my buster machines can use both of these printers just as if they
>> were plugged into that machine, but a machine shop full of sawdust and
>> metal shavings is not a good printer environment, even if there was room
>> for them, which there isn't.
>>
>> All of my bullseye machines are locked out, printer screen at
>> localhost:631 is empty, and no printers can be found and added.
>>
>> But open a shell, and type "lpstat -t" and it gets the full list of
>> available printers on that same bullseye machine whose cups output is
>> empty.
>>
>> Why?
>
> Take a look at
> https://wiki.debian.org/CUPSQuickPrintQueues
>
> The quick ref is to install avahi-utils and run
> avahi-browse -rt _ipp._tcp | grep URF
>

had to install it, pulled in 7 other pkgs: then:
gene@bpi51:~$ avahi-browse -rt _ipp._tcp | grep URF
txt = ["printer-type=0x80300E" "printer-state=3" "Color=T" "TLS=1.2"
"UUID=831942b6-acfd-3e55-7013-00336f687aa2" "URF=DM3"
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
"product=(MFC-J6920DW)" "priority=0" "note=letss see if this works"
"adminurl=https://coyote.local.:631/printers/Brother_MFC-J6920DW_photo"
"ty=Brother MFC-J6920DW CUPS" "rp=printers/Brother_MFC-J6920DW_photo"
"qtotal=1" "txtvers=1"]
txt = ["printer-type=0x80300E" "printer-state=3" "Color=T" "TLS=1.2"
"UUID=58daf55b-1dc3-31b0-7442-4a936bde800c" "URF=DM3"
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
"product=(MFC-J6920DW)" "priority=0" "note=coyote.den duplex bottom
tray" "adminurl=https://coyote.local.:631/printers/MFCJ6920DW"
"ty=Brother MFC-J6920DW CUPS" "rp=printers/MFCJ6920DW" "qtotal=1"
"txtvers=1"]
txt = ["printer-type=0x809016" "printer-state=3" "Duplex=T"
"TLS=1.2" "UUID=36139eb5-df51-332f-4f80-ebf162ecc0ae" "URF=DM3"
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
"product=(Brother HL-L2320D series)" "priority=0"
"adminurl=https://coyote.local.:631/printers/HLL2320D" "ty=Brother
HL-L2320D for CUPS" "rp=printers/HLL2320D" "qtotal=1" "txtvers=1"]
txt = ["printer-type=0x809016" "printer-state=3" "Duplex=T"
"TLS=1.2" "UUID=391b5af9-9bac-3249-65f0-795f553651fe" "URF=DM3"
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
"product=(Brother HL-L2320D series)" "priority=0" "note=floor in den"
"adminurl=https://coyote.local.:631/printers/Brother_HL-L2320D_series"
"ty=Brother HL-L2320D for CUPS" "rp=printers/Brother_HL-L2320D_series"
"qtotal=1" "txtvers=1"]

> If you get a line matching URF the printer supports the AirPrint
> service. Install cups and see if it works (which is all that I needed
> to do to get the printer working). If no, what does
>

cups already installed as part of armbian

> avahi-browse -rt _ipp._tcp
gene@bpi51:~$ avahi-browse -rt _ipp._tcp
+ eth0 IPv4 Brother HL-L2320D series @ coyote Internet
Printer local
+ eth0 IPv4 Brother MFC-J6920DW @ coyote Internet
Printer local
+ eth0 IPv4 HLL2320D @ coyote Internet
Printer local
+ eth0 IPv4 MFCJ6920DW _tray_2 @ coyote Internet
Printer local
= eth0 IPv4 Brother HL-L2320D series @ coyote Internet
Printer local
hostname = [coyote.local]
address = [192.168.71.3]
port = [631]
txt = ["printer-type=0x809016" "printer-state=3" "Duplex=T"
"TLS=1.2" "UUID=391b5af9-9bac-3249-65f0-795f553651fe" "URF=DM3"
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
"product=(Brother HL-L2320D series)" "priority=0" "note=floor in den"
"adminurl=https://coyote.local.:631/printers/Brother_HL-L2320D_series"
"ty=Brother HL-L2320D for CUPS" "rp=printers/Brother_HL-L2320D_series"
"qtotal=1" "txtvers=1"]
= eth0 IPv4 Brother MFC-J6920DW @ coyote Internet
Printer local
hostname = [coyote.local]
address = [192.168.71.3]
port = [631]
txt = ["printer-type=0x80300E" "printer-state=3" "Color=T" "TLS=1.2"
"UUID=831942b6-acfd-3e55-7013-00336f687aa2" "URF=DM3"
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
"product=(MFC-J6920DW)" "priority=0" "note=letss see if this works"
"adminurl=https://coyote.local.:631/printers/Brother_MFC-J6920DW_photo"
"ty=Brother MFC-J6920DW CUPS" "rp=printers/Brother_MFC-J6920DW_photo"
"qtotal=1" "txtvers=1"]
= eth0 IPv4 HLL2320D @ coyote Internet
Printer local
hostname = [coyote.local]
address = [192.168.71.3]
port = [631]
txt = ["printer-type=0x809016" "printer-state=3" "Duplex=T"
"TLS=1.2" "UUID=36139eb5-df51-332f-4f80-ebf162ecc0ae" "URF=DM3"
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
"product=(Brother HL-L2320D series)" "priority=0"
"adminurl=https://coyote.local.:631/printers/HLL2320D" "ty=Brother
HL-L2320D for CUPS" "rp=printers/HLL2320D" "qtotal=1" "txtvers=1"]
= eth0 IPv4 MFCJ6920DW _tray_2 @ coyote Internet
Printer local
hostname = [coyote.local]
address = [192.168.71.3]
port = [631]
txt = ["printer-type=0x80300E" "printer-state=3" "Color=T" "TLS=1.2"
"UUID=58daf55b-1dc3-31b0-7442-4a936bde800c" "URF=DM3"
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
"product=(MFC-J6920DW)" "priority=0" "note=coyote.den duplex bottom
tray" "adminurl=https://coyote.local.:631/printers/MFCJ

>
> and
>
> systemctl status avahi-daemon
>
> show you?
>

gene@bpi51:~$ systemctl status avahi-daemon
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled;
vendor preset: enabled)
Active: active (running) since Mon 2023-05-01 02:13:38 -05; 11min ago
TriggeredBy: ● avahi-daemon.socket
Main PID: 5081 (avahi-daemon)
Status: "avahi-daemon 0.8 starting up."
Tasks: 2 (limit: 4207)
Memory: 788.0K
CPU: 166ms
CGroup: /system.slice/avahi-daemon.service
├─5081 avahi-daemon: running [bpi51.local]
└─5083 avahi-daemon: chroot helper

May 01 02:13:38 bpi51 avahi-daemon[5081]: No service file found in
/etc/avahi/services.
May 01 02:13:38 bpi51 avahi-daemon[5081]: *** WARNING: Detected another
IPv4 mDNS stack running on this host. This makes mDNS unreliable and is
thus not>
May 01 02:13:38 bpi51 avahi-daemon[5081]: Joining mDNS multicast group
on interface eth0.IPv4 with address 192.168.71.9.
May 01 02:13:38 bpi51 avahi-daemon[5081]: New relevant interface
eth0.IPv4 for mDNS.
May 01 02:13:38 bpi51 avahi-daemon[5081]: Joining mDNS multicast group
on interface lo.IPv4 with address 127.0.0.1.
May 01 02:13:38 bpi51 avahi-daemon[5081]: New relevant interface lo.IPv4
for mDNS.
May 01 02:13:38 bpi51 avahi-daemon[5081]: Network interface enumeration
completed.
May 01 02:13:38 bpi51 avahi-daemon[5081]: Registering new address record
for 192.168.71.9 on eth0.IPv4.
May 01 02:13:38 bpi51 avahi-daemon[5081]: Registering new address record
for 127.0.0.1 on lo.IPv4.
May 01 02:13:39 bpi51 avahi-daemon[5081]: Server startup complete. Host
name is bpi51.local. Local service cookie is 4247089512.

Went to machine, ff already running for octoprint tab opened to
localhost:631, no printers for a printer search.

So cups still cannot see the shares but only for a bullseye install,
buster installs work just fine.

??

Thanks Lee.

> Regards,
> Lee
> .

Cheers, Gene Heskett.
--

[john doe]

On 5/1/23 01:05, gene heskett wrote:
> Greetings all;
>
> I have a mixed home network, some buster, some bullseye, all up to date
> a/o yesterday.
>
> I have 2 printers shared on this bullseye main box, available as 5 or 6
> printers, each configured in cups to do a specific job. Good printers,
> both running on brother's own linux drivers for that printer.
>
> All my buster machines can use both of these printers just as if they
> were plugged into that machine, but a machine shop full of sawdust and
> metal shavings is not a good printer environment, even if there was room
> for them, which there isn't.
>
> All of my bullseye machines are locked out, printer screen at
> localhost:631 is empty, and no printers can be found and added.
>
> But open a shell, and type "lpstat -t" and it gets the full list of
> available printers on that same bullseye machine whose cups output is
> empty.
>
> Why?
>

Please refrain from polluting the list when you do not get an answer.

--
John Doe

[to...@tuxteam.de]

On Mon, May 01, 2023 at 09:37:59AM +0200, john doe wrote:

[...]

> Please refrain from polluting the list when you do not get an answer.

I think repeating a question after a while doesn't count as
"polluting". That's what debian-user is for, after all.

Cheers
--
t

[Brian]

Indeed. Persistaence has a place and may pay off.

--
Brian.

[Brian]

On Mon 01 May 2023 at 03:29:28 -0400, gene heskett wrote:

> > avahi-browse -rt _ipp._tcp
> gene@bpi51:~$ avahi-browse -rt _ipp._tcp
> + eth0 IPv4 Brother HL-L2320D series @ coyote Internet Printer
> local
> + eth0 IPv4 Brother MFC-J6920DW @ coyote Internet Printer
> local
> + eth0 IPv4 HLL2320D @ coyote Internet Printer
> local
> + eth0 IPv4 MFCJ6920DW _tray_2 @ coyote Internet Printer
> local

You have exactly four (not five or six) print queues manually set up on
the CUPS server coyote (192.168.71.3). It is assumed that when sat at
coyote it is possible to print to any of Brother HL-L2320D series, Brother
MFC-J6920DW, HLL2320D and MFCJ6920DW _tray_2. Im particular - can you
print to HLL2320D from the server?

[...]

> = eth0 IPv4 HLL2320D @ coyote Internet Printer
> local
> hostname = [coyote.local]
> address = [192.168.71.3]
> port = [631]
> txt = ["printer-type=0x809016" "printer-state=3" "Duplex=T" "TLS=1.2"
> "UUID=36139eb5-df51-332f-4f80-ebf162ecc0ae" "URF=DM3" "pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
> "product=(Brother HL-L2320D series)" "priority=0"
> "adminurl=https://coyote.local.:631/printers/HLL2320D" "ty=Brother HL-L2320D
> for CUPS" "rp=printers/HLL2320D" "qtotal=1" "txtvers=1"]

As well as three other printers, the host bpi51 sees the shared HLL2320D @ coyote
queue via mDNS/DNS-SD. All is well and good up to now. Let's have

lpstat -l -e
lpstat -a
lpinfo -v

from bpi51.

--
Brian.

[gene heskett]

On 5/1/23 08:56, Brian wrote:
> On Mon 01 May 2023 at 03:29:28 -0400, gene heskett wrote:
>
>>> avahi-browse -rt _ipp._tcp
>> gene@bpi51:~$ avahi-browse -rt _ipp._tcp
>> + eth0 IPv4 Brother HL-L2320D series @ coyote Internet Printer
>> local
>> + eth0 IPv4 Brother MFC-J6920DW @ coyote Internet Printer
>> local
>> + eth0 IPv4 HLL2320D @ coyote Internet Printer
>> local
>> + eth0 IPv4 MFCJ6920DW _tray_2 @ coyote Internet Printer
>> local
>
> You have exactly four (not five or six) print queues manually set up on
> the CUPS server coyote (192.168.71.3). It is assumed that when sat at
> coyote it is possible to print to any of Brother HL-L2320D series, Brother
> MFC-J6920DW, HLL2320D and MFCJ6920DW _tray_2. Im particular - can you
> print to HLL2320D from the server?
>

Yes, and from any buster machine on my local network.

> [...]
>
>> = eth0 IPv4 HLL2320D @ coyote Internet Printer
>> local
>> hostname = [coyote.local]
>> address = [192.168.71.3]
>> port = [631]
>> txt = ["printer-type=0x809016" "printer-state=3" "Duplex=T" "TLS=1.2"
>> "UUID=36139eb5-df51-332f-4f80-ebf162ecc0ae" "URF=DM3" "pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
>> "product=(Brother HL-L2320D series)" "priority=0"
>> "adminurl=https://coyote.local.:631/printers/HLL2320D" "ty=Brother HL-L2320D
>> for CUPS" "rp=printers/HLL2320D" "qtotal=1" "txtvers=1"]
>
> As well as three other printers, the host bpi51 sees the shared HLL2320D @ coyote
> queue via mDNS/DNS-SD. All is well and good up to now. Let's have
>
> lpstat -l -e

gene@bpi51:~$ lpstat -l -e
Brother_HL_L2320D_series_coyote network none
ipps://Brother%20HL-L2320D%20series%20%40%20coyote._ipps._tcp.local/cups
Brother_MFC_J6920DW_coyote network none
ipps://Brother%20MFC-J6920DW%20%40%20coyote._ipps._tcp.local/cups
HLL2320D_coyote network none
ipps://HLL2320D%20%40%20coyote._ipps._tcp.local/cups
MFCJ6920DW_tray_2_coyote network none
ipps://MFCJ6920DW%20_tray_2%20%40%20coyote._ipps._tcp.local/cups
PDF permanent ipp://localhost/printers/PDF cups-pdf:/

> lpstat -a
gene@bpi51:~$ lpstat -a
PDF accepting requests since Fri 02 Dec 2022 11:13:10 PM -05

> lpinfo -v
gene@bpi51:~$ lpinfo -v
-bash: lpinfo: command not found
gene@bpi51:~$ sudo apt install lpinfo
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package lpinfo

>
> from bpi51.
>
Thank you Brian

Take care and stay well.

[David Wright]

On Mon 01 May 2023 at 09:39:51 (-0400), gene heskett wrote:
> > lpinfo -v
> gene@bpi51:~$ lpinfo -v
> -bash: lpinfo: command not found
> gene@bpi51:~$ sudo apt install lpinfo
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package lpinfo

You need root:

# lpinfo -v
network beh
network lpd
file cups-brf:/
network socket
network ipps
network https
network ipp
network http
file cups-pdf:/
network dnssd://Brother%20HL-L2390DW._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-90324b75e771
network ipp://Brother%20HL-L2390DW._ipp._tcp.local/
network lpd://BRW90324B75E771/BINARY_P1
#

Cheers,
David.

[Jeffrey Walton]

On Mon, May 1, 2023 at 9:40 AM gene heskett <ghes...@shentel.net> wrote:
>
> [...]

> > lpinfo -v
> gene@bpi51:~$ lpinfo -v
> -bash: lpinfo: command not found
> gene@bpi51:~$ sudo apt install lpinfo
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package lpinfo

$ apt-cache search lpinfo
$ dpkg -S lpinfo
cups-client: /usr/share/man/de/man8/lpinfo.8.gz
cups-client: /usr/share/man/man8/lpinfo.8.gz
cups-server-common: /usr/share/cups/doc-root/help/man-lpinfo.html
cups-client: /usr/sbin/lpinfo
cups-client: /usr/share/man/fr/man8/lpinfo.8.gz

[Brian]

On Mon 01 May 2023 at 09:39:51 -0400, gene heskett wrote:

> gene@bpi51:~$ lpstat -l -e
> Brother_HL_L2320D_series_coyote network none
> ipps://Brother%20HL-L2320D%20series%20%40%20coyote._ipps._tcp.local/cups
>
> Brother_MFC_J6920DW_coyote network none
> ipps://Brother%20MFC-J6920DW%20%40%20coyote._ipps._tcp.local/cups
>
> HLL2320D_coyote network none
> ipps://HLL2320D%20%40%20coyote._ipps._tcp.local/cups
>
> MFCJ6920DW_tray_2_coyote network none
> ipps://MFCJ6920DW%20_tray_2%20%40%20coyote._ipps._tcp.local/cups

There you are! CUPS sees all four print queues shared by coyote. At this
stage we are golden. Note that all four are designated as "network".

> PDF permanent ipp://localhost/printers/PDF cups-pdf:/

This is a manual queue (permanent) set up locally on bpi51. It isn't of any
further interest.

> gene@bpi51:~$ lpstat -a
> PDF accepting requests since Fri 02 Dec 2022 11:13:10 PM -05

You may care to take note that 'lpstat -a' and 'lpstat -t' only show local
printers (permanent) and not those that are on the network. That also goes
for the Printers section at localhost:631.

Local printers can also be auto-setup by cups-browsed. You do not have it
installed/running. Thar's OK; there isn't any obligation (or for that matter,
any need) to use it. Having mentioned it, we will now completely put it out
of our minds.

> gene@bpi51:~$ lpinfo -v
> -bash: lpinfo: command not found

sudo lpinfo -v

Your printing situation appears to be a sane one, so now for a test. Do

lp -d HLL2320D_coyote ANY_FILE_YOU_WANT

--
Brian.

[Brian]

Indeed you do. I forgot that root privilege is required because the USB bus
is probed.

--
Brian.

[gene heskett]

> .
Ah so
gene@bpi51:~$ sudo lpinfo -v
[sudo] password for gene:
Sorry, try again.
[sudo] password for gene:
network beh
network socket
network http
network ipps
network lpd
network https
network ipp
file cups-brf:/
file cups-pdf:/
network
dnssd://Brother%20HL-L2320D%20series%20%40%20coyote._ipp._tcp.local/cups?uuid=391b5af9-9bac-3249-65f0-795f553651fe
network
dnssd://Brother%20MFC-J6920DW%20%40%20coyote._ipp._tcp.local/cups?uuid=831942b6-acfd-3e55-7013-00336f687aa2
network
dnssd://HLL2320D%20%40%20coyote._ipp._tcp.local/cups?uuid=36139eb5-df51-332f-4f80-ebf162ecc0ae
network
dnssd://MFCJ6920DW%20_tray_2%20%40%20coyote._ipp._tcp.local/cups?uuid=58daf55b-1dc3-31b0-7442-4a936bde800c

Thats better, but does it show "why"

[gene heskett]

On 5/1/23 08:56, Brian wrote:

gene@bpi51:~$ lpstat -l -e
Brother_HL_L2320D_series_coyote network none
ipps://Brother%20HL-L2320D%20series%20%40%20coyote._ipps._tcp.local/cups
Brother_MFC_J6920DW_coyote network none
ipps://Brother%20MFC-J6920DW%20%40%20coyote._ipps._tcp.local/cups
HLL2320D_coyote network none
ipps://HLL2320D%20%40%20coyote._ipps._tcp.local/cups
MFCJ6920DW_tray_2_coyote network none
ipps://MFCJ6920DW%20_tray_2%20%40%20coyote._ipps._tcp.local/cups

PDF permanent ipp://localhost/printers/PDF cups-pdf:/

> lpstat -a
> lpinfo -v
>
> from bpi51.
>

[gene heskett]

Is not working, shell appears frozen but eventually returns:
gene@bpi51:~$ lp -d HLL2320D_coyote printer.cfg
lp: The printer or class does not exist.

[gene heskett]

repeat same error if s sudo is put in front of it.

> Cheers, Gene Heskett.

[Brian]

On Mon 01 May 2023 at 11:02:58 -0400, gene heskett wrote:

> On 5/1/23 10:40, Brian wrote:

[...]

> > Your printing situation appears to be a sane one, so now for a test. Do
> >
> > lp -d HLL2320D_coyote ANY_FILE_YOU_WANT
> >
> Is not working, shell appears frozen but eventually returns:
> gene@bpi51:~$ lp -d HLL2320D_coyote printer.cfg
> lp: The printer or class does not exist.

But HLL2320D_coyote does exist. It is seen in the outputs of 'lpstat -l -e'
and 'sudo lpinfo -v'. Give

lpoptopns -p HLL2320D_coyote
lpoptions -p HLL2320D_coyote -l

--
Brian.

[Brian]

THe network is probed and the dnssd backend of CUPS find the same four printers as
'lpsta -l -e' does.

--
Brian.

[gene heskett]

gene@bpi51:~$ lpoptions -p HLL2320D_coyote
device-uri=ipps://HLL2320D%20%40%20coyote._ipps._tcp.local/cups
printer-info='HLL2320D @ coyote' printer-make-and-model='Brother
HL-L2320D series' printer-type=25202710

> lpoptions -p HLL2320D_coyote -l
gene@bpi51:~$ lpoptions -p HLL2320D_coyote -l
lpoptions: Unable to get PPD file for HLL2320D_coyote: The printer or
class does not exist.

>

[Brian]

On Mon 01 May 2023 at 11:39:29 -0400, gene heskett wrote:

> On 5/1/23 11:28, Brian wrote:
> > On Mon 01 May 2023 at 11:02:58 -0400, gene heskett wrote:
> >
> > > On 5/1/23 10:40, Brian wrote:
> >
> > [...]
> >
> > > > Your printing situation appears to be a sane one, so now for a test. Do
> > > >
> > > > lp -d HLL2320D_coyote ANY_FILE_YOU_WANT
> > > >
> > > Is not working, shell appears frozen but eventually returns:
> > > gene@bpi51:~$ lp -d HLL2320D_coyote printer.cfg
> > > lp: The printer or class does not exist.
> >
> > But HLL2320D_coyote does exist. It is seen in the outputs of 'lpstat -l -e'
> > and 'sudo lpinfo -v'. Give
> >
> > lpoptopns -p HLL2320D_coyote
> gene@bpi51:~$ lpoptions -p HLL2320D_coyote
> device-uri=ipps://HLL2320D%20%40%20coyote._ipps._tcp.local/cups
> printer-info='HLL2320D @ coyote' printer-make-and-model='Brother HL-L2320D
> series' printer-type=25202710

The print queue specified by -p is queried for some information about itself.
Its reponse is given and it seems a very reasonable one.

> > lpoptions -p HLL2320D_coyote -l
> gene@bpi51:~$ lpoptions -p HLL2320D_coyote -l
> lpoptions: Unable to get PPD file for HLL2320D_coyote: The printer or class
> does not exist.

The -l option asks the queue for the specific options it offers. The response
indicates something wrong with CUPS on bpi51. I haven't any problem when doing
this and getting sensible outputs on my Debian unstable machine.

Assuming your buster machines (which are working) have similar setups to bpi51,
you couls try the two commands (and all the others in this thread) on one of
those.

--
Brian.

[gene heskett]

one of those machines reports this for the -l option:

gene@sixty40:~$ lpoptions -p HLL2320D_coyote -l
PageSize/Media Size: Custom.WIDTHxHEIGHT *Letter Legal Executive
FanFoldGermanLegal A4 A5 A6 Env10 EnvMonarch EnvDL EnvC5 ISOB5 B5 ISOB6
B6 4x6 Postcard DoublePostcardRotated EnvYou4 195x270mm 184x260mm
197x273mm CUSTOM1 CUSTOM2 CUSTOM3
BrMediaType/MediaType: *PLAIN THIN THICK THICKERPAPER2 BOND ENV ENVTHICK
ENVTHIN RECYCLED
InputSlot/InputSlot: MANUAL *TRAY1
Duplex/Duplex: DuplexTumble *DuplexNoTumble None
Resolution/Resolution: 300dpi *600dpi 2400x600dpi
TonerSaveMode/Toner Save: *OFF ON
Sleep/Sleep Time [Min.]: *PrinterDefault 2minutes 10minutes 30minutes

the diff between a working buster from an ls -l /etc/cups showing:
gene@GO704:~/linuxcnc/src$ ls -l /etc/cups
total 64
-rw-r--r-- 1 root root 27303 Apr 10 2019 cups-browsed.conf
-rw-r--r-- 1 root root 6402 Feb 26 15:05 cupsd.conf
-rw-r--r-- 1 root root 2923 May 23 2022 cups-files.conf
drwxr-xr-x 2 root lp 4096 May 1 00:00 ppd
-rw------- 1 root lp 1882 May 1 00:00 printers.conf
-rw------- 1 root lp 111 May 1 00:00 printers.conf.O
drwx------ 2 root lp 4096 May 23 2022 ssl
-rw-r----- 1 root lp 387 May 1 00:00 subscriptions.conf
-rw-r----- 1 root lp 93 May 1 00:00 subscriptions.conf.O
which works fine, And a non-working bullseye:
gene@bpi51:~$ ls -l /etc/cups/
total 100
-rw------- 1 root lp 111 Dec 2 23:13 classes.conf
-rw-r--r-- 1 root root 30436 Mar 14 2022 cups-browsed.conf
-rw-r--r-- 1 root root 6456 Oct 15 2022 cupsd.conf
-rw-r--r-- 1 root root 3047 May 23 2022 cups-files.conf
-rw-r--r-- 1 root root 10982 Jan 2 2021 cups-pdf.conf
drwxr-xr-x 2 root root 4096 May 23 2022 interfaces
drwxr-xr-x 2 root lp 4096 Dec 2 23:13 ppd
-rw------- 1 root lp 529 May 1 10:37 printers.conf
-rw------- 1 root lp 529 May 1 10:36 printers.conf.O
-rw-r--r-- 1 root root 240 Oct 15 2022 raw.convs
-rw-r--r-- 1 root root 211 Oct 15 2022 raw.types
-rw-r--r-- 1 root root 142 May 23 2022 snmp.conf
drwx------ 2 root lp 4096 May 23 2022 ssl
-rw-r----- 1 root lp 524 May 1 00:00 subscriptions.conf
-rw-r----- 1 root lp 234 May 1 00:00 subscriptions.conf.O

So call me puzzled. I've been called worse.;o)>

[gene heskett]

Which isn't quite a 1:1 comparison as that will be bookworm shortly.

Or, should I update the bullseyes to unstable? IDK and I'm not even sure
how...

> Assuming your buster machines (which are working) have similar setups to bpi51,

Which is a bullseye machine. And has a totally different content to the
/etc/cups directory as shown by my last post, much more complex on the
bullseye installs that don't work.

> you couls try the two commands (and all the others in this thread) on one of
> those.
>

I'd think I could start by comparing cupsd.conf's, but miss And I can't
see the trees for all this forest in the way in both, but missing is a
client.conf. I think... But that is probably whats wrong, me thinking.

[Brian]

On Mon 01 May 2023 at 13:03:50 -0400, gene heskett wrote:

> On 5/1/23 12:30, Brian wrote:
> >
> > Assuming your buster machines (which are working) have similar setups to bpi51,
> > you couls try the two commands (and all the others in this thread) on one of
> > those.
> >
> one of those machines reports this for the -l option:
>
> gene@sixty40:~$ lpoptions -p HLL2320D_coyote -l
> PageSize/Media Size: Custom.WIDTHxHEIGHT *Letter Legal Executive
> FanFoldGermanLegal A4 A5 A6 Env10 EnvMonarch EnvDL EnvC5 ISOB5 B5 ISOB6 B6
> 4x6 Postcard DoublePostcardRotated EnvYou4 195x270mm 184x260mm 197x273mm
> CUSTOM1 CUSTOM2 CUSTOM3
> BrMediaType/MediaType: *PLAIN THIN THICK THICKERPAPER2 BOND ENV ENVTHICK
> ENVTHIN RECYCLED
> InputSlot/InputSlot: MANUAL *TRAY1
> Duplex/Duplex: DuplexTumble *DuplexNoTumble None
> Resolution/Resolution: 300dpi *600dpi 2400x600dpi
> TonerSaveMode/Toner Save: *OFF ON
> Sleep/Sleep Time [Min.]: *PrinterDefault 2minutes 10minutes 30minutes

Looks reasonable. A similar command on the server should give a similar output.

The reason 'lp -d HLL2320D_coyote printer.cfg' failed is because CUPS is unable
to query the HLL2320D_coyote printer for its attributes. Printing from anything
else, such as Firefox, will also fail. CUPS on the bullseye machine appears to
be broken.

[...]

A possible way forward is to execute

sudo lpadmin -p HLL2320D-RAW -v ipp://192.168.71.3:631/printers/HLL2320D -E -m raw

and try

lp -d HLL2320D-RAW printer.cfg

--
Brian.

[Brian]

On Mon 01 May 2023 at 13:22:47 -0400, gene heskett wrote:

> On 5/1/23 12:30, Brian wrote:

[...]

> > The -l option asks the queue for the specific options it offers. The response
> > indicates something wrong with CUPS on bpi51. I haven't any problem when doing
> > this and getting sensible outputs on my Debian unstable machine.
>
> Which isn't quite a 1:1 comparison as that will be bookworm shortly.
>
> Or, should I update the bullseyes to unstable? IDK and I'm not even sure
> how...

Forget about doing that. I was merely commenting that my Debian did not
behave like yours. Is yours a fruit-flavoured varian?

> > Assuming your buster machines (which are working) have similar setups to bpi51,
>
> Which is a bullseye machine. And has a totally different content to the
> /etc/cups directory as shown by my last post, much more complex on the
> bullseye installs that don't work.

THe difference is highly likely to be relevant. You are grasping at straws.

> > you couls try the two commands (and all the others in this thread) on one of
> > those.
> >
> I'd think I could start by comparing cupsd.conf's, but miss And I can't see
> the trees for all this forest in the way in both, but missing is a
> client.conf. I think... But that is probably whats wrong, me thinking.

A client.conf is unneeded on a well-behaved CUPS system that obtains info
from avahi-daemon.

--
Brian.

[debia...@howorth.org.uk]

gene heskett <ghes...@shentel.net> wrote:

> I'd think I could start by comparing cupsd.conf's, but miss And I
> can't see the trees for all this forest in the way in both, but
> missing is a client.conf. I think... But that is probably whats
> wrong, me thinking.

Your directory listings showed that both had a ppd directory, but you
didn't show the content of those directories. Since your error message
was specifically that it couldn't find the PPD, the first thing I'd do
is compare those two directories.

[Brian]

The message was not about not being able to *find* a PPD. Finding something
implies it already exists. Here is the message againn:

> lpoptions: Unable to get PPD file for HLL2320D_coyote: The printer or class
> does not exist.

--
Brian.

[gene heskett]

which gets me this warning:
gene@bpi51:~$ sudo lpadmin -p HLL2320D-RAW -v

ipp://192.168.71.3:631/printers/HLL2320D -E -m raw

[sudo] password for gene:
lpadmin: Raw queues are deprecated and will stop working in a future
version of CUPS.
lpadmin: Use the 'everywhere' model for shared printers.

And I wouldn't use the everywhere option ever as it cripples the printer
down to the lowest common performing option list, losing among other
things, the duplex ability. So it MUST use the Brother driver.

>
> and try
>
then I ran this w/o the sudo:
> lp -d HLL2320D-RAW printer.cfg
And got this:
gene@bpi51:~$ lp -d HLL2320D-RAW printer.cfg
request id is HLL2320D-RAW-1 (1 file(s))

printing the file in portrait mode, full duplex, but the file is wider
and I would normally put it in landscape mode to reduce the
auto-word-wrapping confusion. Does -o landscape still work with the raw
option?

Yes, provided the -olandscape is after the -d argument. That file is a
3d printer description for klipper, 5 pages in landscape mode. And is
the first and 2nd time I've been able to print it. Thank you very much.
Can we continue, making a shell script to do this again with all
variations available for the -o options of lp?

Take care & stay well Brian.

[gene heskett]

in the past, its been required to nuke any and all instances found with
avahi in its name in order to get rid of the totally bogus
169.xx.xxx.xxx. default route address as is now reported by ip r after a
reboot. This has been true even before jessie. However I've now
re-installed it on two of these armbian bullseye machines w/o losing my
network. Perhaps it has learned some manners since jessie? Network
Manager, my other major headache certainly has.

Take care and stay well Brian.

[gene heskett]

The ppd dirs are empty.

And if a copy/paste from this machine, hosting the printers fixes it on
the other bullseye machines so these printers are available to whomever
wants to use them, like geany or okular etc, can we create a cups bug
entry? Perms on those empty ppd dirs are:
gene@bpi54:~$ ls -l /etc/cups
total 80
-rw-r--r-- 1 root root 30 Apr 8 20:07 client.conf
-rw-r--r-- 1 root root 30456 Apr 14 03:14 cups-browsed.conf
-rw-r--r-- 1 root root 6486 Apr 30 05:09 cupsd.conf

-rw-r--r-- 1 root root 3047 May 23 2022 cups-files.conf

drwxr-xr-x 2 root root 4096 May 23 2022 interfaces

drwxr-xr-x 2 root lp 4096 May 23 2022 ppd

-rw-r--r-- 1 root root 240 Oct 15 2022 raw.convs
-rw-r--r-- 1 root root 211 Oct 15 2022 raw.types
-rw-r--r-- 1 root root 142 May 23 2022 snmp.conf
drwx------ 2 root lp 4096 May 23 2022 ssl

-rw-r----- 1 root lp 93 Feb 6 23:41 subscriptions.conf
-rw-r----- 1 root lp 335 Feb 6 23:35 subscriptions.conf.O
gene@bpi54:~$ ls -l /etc/cups/ppd
total 0

So it looks to me like cups, to add a printer, needs to be either root,
ask a sudo pw, or be a member of group lp.

But group lp is bereft of any other members with "lp:x:7:" as its one
and only member, but cups on these machines has yet to ask me for a pw.
This looks like it could be part of the original show stopper problem?
Or, am I overthinking this again?

[gene heskett]

On 5/1/23 16:00, debia...@howorth.org.uk wrote:

The 1st armbian, bpi51, /etc/cups/ppd does contain the PDF generator PPD
The 4th one, bpi54 /etc/cups/ppd is empty. All were installed with the
same bullseye 11.6 installer. The other two are presently powered down
in the middle of building a quad of 3d printers around them.

I might be getting on in the middle of my 88th year here, but I can
still carve useful things in OpenSCAD and in gcode. At the link in my
sig you'll find a link to this machine, and in that link are some pix of
what I'm doing. I wrote every byte of the gcode that carves those wooden
screws in a couple of those pix.

Stronger by quite a bit than anything you can get from fleabay at any price.

[gene heskett]

And it did not exist until the lpadmin created it.

[Brian]

On Mon 01 May 2023 at 17:53:08 -0400, gene heskett wrote:

> On 5/1/23 13:34, Brian wrote:

[...]

> > A possible way forward is to execute
> >
> > sudo lpadmin -p HLL2320D-RAW -v ipp://192.168.71.3:631/printers/HLL2320D -E -m raw
> which gets me this warning:
> gene@bpi51:~$ sudo lpadmin -p HLL2320D-RAW -v
> ipp://192.168.71.3:631/printers/HLL2320D -E -m raw
> [sudo] password for gene:
> lpadmin: Raw queues are deprecated and will stop working in a future version
> of CUPS.

A standard warning that is clear enough.

> lpadmin: Use the 'everywhere' model for shared printers.
>
> And I wouldn't use the everywhere option ever as it cripples the printer
> down to the lowest common performing option list, losing among other things,
> the duplex ability. So it MUST use the Brother driver.

Your demand is granted. -m raw uses the Brother driver on coyote.

> >
> > and try
> >
> then I ran this w/o the sudo:
> > lp -d HLL2320D-RAW printer.cfg
> And got this:
> gene@bpi51:~$ lp -d HLL2320D-RAW printer.cfg
> request id is HLL2320D-RAW-1 (1 file(s))

That's OK.

> printing the file in portrait mode, full duplex, but the file is wider and I
> would normally put it in landscape mode to reduce the auto-word-wrapping
> confusion. Does -o landscape still work with the raw option?
>
> Yes, provided the -olandscape is after the -d argument. That file is a 3d
> printer description for klipper, 5 pages in landscape mode. And is the
> first and 2nd time I've been able to print it. Thank you very much.
> Can we continue, making a shell script to do this again with all variations
> available for the -o options of lp?

See the lpadmin manual for how to set up different queues with differnent
options on bpi51.

Glad you are now printing, but you really need to fix the CUPS installation.

--
Brian.

[zithro]

On 01 May 2023 14:53, Brian wrote:
> On Mon 01 May 2023 at 13:41:10 +0200, to...@tuxteam.de wrote:
>
>> On Mon, May 01, 2023 at 09:37:59AM +0200, john doe wrote:
>>
>> [...]
>>
>>> Please refrain from polluting the list when you do not get an answer.
>>
>> I think repeating a question after a while doesn't count as
>> "polluting". That's what debian-user is for, after all.
>
> Indeed. Persistaence has a place and may pay off.
>

Indeed, it seems it has paid off, as it works now for Gene !

The Brian-Gene exchanges are now set in stone, and can now serve as a
step-by-step debug guide for CUPS.

I'm glad Gene followed suggestions this time, right Gene ? ;)

Although I was afraid when I saw :

*** WARNING: Detected another IPv4 mDNS stack running on this host. This
makes mDNS unreliable and is thus not>

Is that expected at 1st avahi start ?

Second question: is that possible to use CUPS/printing without avahi ?

[gene heskett]

Absolutely, up to bullseye for both buster and bullseye, but not from
bullseye to bullseye.

[Brian]

On Thu 04 May 2023 at 15:57:49 -0400, gene heskett wrote:

> On 5/4/23 15:43, zithro wrote:
> > On 01 May 2023 14:53, Brian wrote:

[...]

> > Second question: is that possible to use CUPS/printing without avahi ?
> >
> Absolutely, up to bullseye for both buster and bullseye, but not from
> bullseye to bullseye.

avahi-daemon is recommended by cups-daemong. Printing is *always* possible
without its being on the system, especially if it's desired to make things
difficult for all users. I'm afraid the remainder of the sentence is very
misleading and amounts to nonsense.

--
Brian.

[gene heskett]

What nonsense? I have repeatedly asked why printers shared from this
machine, that are seen and usable from any buster machine on my net, but
cannot be seen or used by any other bullseye machine on this same net by
localhost:631 on that bullseye machine.

lpstat and friends can see and use them, but no cups related stuff
installed on a bullseye install can.

And no one can tell me why... none of the editors or pdf readers that
have a print this dialog, geany, evince, etc, can't see or use these
printers. I thought maybe we were on the trail of finding a solution,
but you were happy & went away when an lp command line worked. But way
too many of the other utils ignore any attempt to use lp if they can't
use cups. For me, its a serious problem. Yes, lp works, but I'm back to
the amiga, ghostscript 5.05 I had to build and an array of shell scripts
I wrote to print a multipage document. That is 1990 stuff. I just looked
at a calendar and found its now 2023. Seems to me that 33 years later,
we should have made more progress than I can see here.

Take care & stay well Brian.

[Brian]

On Fri 05 May 2023 at 11:40:21 -0400, gene heskett wrote:

> On 5/5/23 10:08, Brian wrote:
> > On Thu 04 May 2023 at 15:57:49 -0400, gene heskett wrote:
> >
> > > On 5/4/23 15:43, zithro wrote:
> > > > On 01 May 2023 14:53, Brian wrote:
> >
> > [...]
> >
> > > > Second question: is that possible to use CUPS/printing without avahi ?
> > > >
> > > Absolutely, up to bullseye for both buster and bullseye, but not from
> > > bullseye to bullseye.
> >
> > avahi-daemon is recommended by cups-daemong. Printing is *always* possible
> > without its being on the system, especially if it's desired to make things
> > difficult for all users. I'm afraid the remainder of the sentence is very
> > misleading and amounts to nonsense.
> >
> What nonsense? I have repeatedly asked why printers shared from this
> machine, that are seen and usable from any buster machine on my net, but
> cannot be seen or used by any other bullseye machine on this same net by
> localhost:631 on that bullseye machine.
>
> lpstat and friends can see and use them, but no cups related stuff installed
> on a bullseye install can.

A very general question was asked. You answered in terms of your own particular
situation:

* An unrevealed non-Debian OS on bpi51.
* A well-known aversion to Avahi.
* An aversion to the everywhere model.
* An output from 'lpoptions -p HLL2320D_coyote -l' that indicates a broken
system.

Your conclusion is that the printing system is in itself is defective and that is
reflected in your response. Their fault - not mine.

> And no one can tell me why... none of the editors or pdf readers that have a
> print this dialog, geany, evince, etc, can't see or use these printers. I
> thought maybe we were on the trail of finding a solution, but you were happy
> & went away when an lp command line worked. But way too many of the other
> utils ignore any attempt to use lp if they can't use cups. For me, its a
> serious problem. Yes, lp works, but I'm back to the amiga, ghostscript 5.05
> I had to build and an array of shell scripts I wrote to print a multipage
> document. That is 1990 stuff. I just looked at a calendar and found its now
> 2023. Seems to me that 33 years later, we should have made more progress
> than I can see here.

I gave you a classic printing solution because New Architecture printing fell apart
*on your system*. I am very much disinclined to dig any further into the setup
you have devised for printing.

--
Brian.

[gene heskett]

On 5/5/23 13:45, Brian wrote:
> On Fri 05 May 2023 at 11:40:21 -0400, gene heskett wrote:
>
>> On 5/5/23 10:08, Brian wrote:
>>> On Thu 04 May 2023 at 15:57:49 -0400, gene heskett wrote:
>>>
>>>> On 5/4/23 15:43, zithro wrote:
>>>>> On 01 May 2023 14:53, Brian wrote:
>>>
>>> [...]
>>>
>>>>> Second question: is that possible to use CUPS/printing without avahi ?
>>>>>
>>>> Absolutely, up to bullseye for both buster and bullseye, but not from
>>>> bullseye to bullseye.
>>>
>>> avahi-daemon is recommended by cups-daemong. Printing is *always* possible
>>> without its being on the system, especially if it's desired to make things
>>> difficult for all users. I'm afraid the remainder of the sentence is very
>>> misleading and amounts to nonsense.
>>>
>> What nonsense? I have repeatedly asked why printers shared from this
>> machine, that are seen and usable from any buster machine on my net, but
>> cannot be seen or used by any other bullseye machine on this same net by
>> localhost:631 on that bullseye machine.
>>
>> lpstat and friends can see and use them, but no cups related stuff installed
>> on a bullseye install can.
>
> A very general question was asked. You answered in terms of your own particular
> situation:
>
> * An unrevealed non-Debian OS on bpi51.

The armbian version of debian bullseye 11.6 which except for the uboot
stuff, uses the debian arm64 repo's for everything else. And which I'm
pretty sure has been posted.

> * A well-known aversion to Avahi.

Which I have now reinstalled, much to my amazement has not insisted on
replacing the default route with a 169.number. My aversion to avahi goes
clear back to long before Jessie because it was not possible to achieve
a working, local 192.168,xx.xx based network with avahi installed.
Avahi, like NM has finally learned some manners.

> * An aversion to the everywhere model.

Because it reduces any printer to the lowest common denominator. No
duplex, no multiple paper trays, huge borders & poor almost unreadable
fonts.

> * An output from 'lpoptions -p HLL2320D_coyote -l' that indicates a broken
> system.

this is bad?
gene@coyote:~$ lpoptions -p HLL2320D_coyote -l
PageSize/Media Size: 184.15x260mm 195.09x269.88mm 200.03x148.17mm 4x6 A4
A5 A6 B5 B6 Env10 EnvC5 EnvDL EnvMonarch EnvYou4 Executive
FanFoldGermanLegal ISOB5 ISOB6 Legal *Letter Postcard roc16k
Custom.WIDTHxHEIGHT
InputSlot/Media Source: *Manual Tray1
ColorModel/Output Mode: FastGray *Gray
Duplex/Duplex: *None DuplexNoTumble DuplexTumble
OutputBin/OutputBin: *FaceDown
cupsPrintQuality/cupsPrintQuality: *Normal

The only thing I don't see is its shared state? but it is.
So why can't another bullseye install use these printers? Buster
machines have 100% transparent access.

> Your conclusion is that the printing system is in itself is defective and that is
> reflected in your response. Their fault - not mine.
>
>> And no one can tell me why... none of the editors or pdf readers that have a
>> print this dialog, geany, evince, etc, can't see or use these printers. I
>> thought maybe we were on the trail of finding a solution, but you were happy
>> & went away when an lp command line worked. But way too many of the other
>> utils ignore any attempt to use lp if they can't use cups. For me, its a
>> serious problem. Yes, lp works, but I'm back to the amiga, ghostscript 5.05
>> I had to build and an array of shell scripts I wrote to print a multipage
>> document. That is 1990 stuff. I just looked at a calendar and found its now
>> 2023. Seems to me that 33 years later, we should have made more progress
>> than I can see here.
>
> I gave you a classic printing solution because New Architecture printing fell apart
> *on your system*. I am very much disinclined to dig any further into the setup
> you have devised for printing.

[Brian]

On Fri 05 May 2023 at 16:32:36 -0400, gene heskett wrote:

> On 5/5/23 13:45, Brian wrote:

[...]

> > * An output from 'lpoptions -p HLL2320D_coyote -l' that indicates a broken
> > system.
>
> this is bad?
> gene@coyote:~$ lpoptions -p HLL2320D_coyote -l
> PageSize/Media Size: 184.15x260mm 195.09x269.88mm 200.03x148.17mm 4x6 A4 A5
> A6 B5 B6 Env10 EnvC5 EnvDL EnvMonarch EnvYou4 Executive FanFoldGermanLegal
> ISOB5 ISOB6 Legal *Letter Postcard roc16k Custom.WIDTHxHEIGHT
> InputSlot/Media Source: *Manual Tray1
> ColorModel/Output Mode: FastGray *Gray
> Duplex/Duplex: *None DuplexNoTumble DuplexTumble
> OutputBin/OutputBin: *FaceDown
> cupsPrintQuality/cupsPrintQuality: *Normal

The commaand has been executed on the server, the machine named coyote. The
machine of interest is bpi51, which gives

> gene@bpi51:~$ lpoptions -p HLL2320D_coyote -l

> lpoptions: Unable to get PPD file for HLL2320D_coyote: The printer or class
> does not exist.

bpi51 is unable to the printer attributes from coyote.

Contrast that with a buster machine:

gene@sixty40:~$ lpoptions -p HLL2320D_coyote -l

> PageSize/Media Size: Custom.WIDTHxHEIGHT *Letter Legal Executive
> FanFoldGermanLegal A4 A5 A6 Env10 EnvMonarch EnvDL EnvC5 ISOB5 B5
> ISOB6 B6 4x6 Postcard DoublePostcardRotated EnvYou4 195x270mm
> 184x260mm 197x273mm CUSTOM1 CUSTOM2 CUSTOM3
> BrMediaType/MediaType: *PLAIN THIN THICK THICKERPAPER2 BOND ENV
> ENVTHICK ENVTHIN RECYCLED
> InputSlot/InputSlot: MANUAL *TRAY1
> Duplex/Duplex: DuplexTumble *DuplexNoTumble None
> Resolution/Resolution: 300dpi *600dpi 2400x600dpi
> TonerSaveMode/Toner Save: *OFF ON
> Sleep/Sleep Time [Min.]: *PrinterDefault 2minutes 10minutes 30minutes

This output would be expected on bpi51.

> The only thing I don't see is its shared state? but it is.
> So why can't another bullseye install use these printers? Buster machines
> have 100% transparent access.

Because bpi51 is unable to get attributes from the server to form a PPD file
for HLL2320D_coyote. That is what needs sorting.

--
Brian.

[gene heskett]

The question then becomes what is stopping it, A further clue, maybe, is
the error log here that reports a lack of auth, but does not say from
where. that precious little to go hunting for. Someone more familiar
with cups might be able to make it spit out more specifics.

Thanks Brian.

[Alex King]

Printing on Linux is poor.  CUPS is poor.  It doesn't work for some (a
lot?) of people.

I have a Brother HL-L2300D printer.  It is connected to my (Debian
bullseye) workstation by USB.  I have CUPS installed.

My printer prints sometime.  Other times, it spins up (makes a noise
like it is about to start printing), but nothing comes out. I can't get
any useful diagnostics to tell me where the problem might be.

My parents, who live some distance away have an HP inkjet printer.  It
works sometimes.  Other times it doesn't.  I get it set up so it's
working and it might work for a while, but it will stop working for no
reason.  There might be several queues for the printer; some work and
some just don't.  A working queue will stop working for no discernible
reason.  Working queues will disappear, new queues will appear seemingly
at random.  The print system will default to an automatically provided
queue that could never work, because it relies on some software
component that is not installed.... etc... etc...

Between my parents and my own system, I have spent 10s or 100s of hours
trying to get a reliable printing system over decades, with many
different printers.  Maybe there were periods where printing worked OK. 
But I haven't managed to achieve reliable printing in the medium term.

I read ESR https://www.catb.org/~esr/writings/cups-horror.html, and my
personal experience is that nothing much has changed in the "driverless"
era.

I've been a sysadmin for 30 odd years, configuring different aspects of
linux (webservers, email servers, DNS, networking, desktop environments
etc.) using open source software.  Some problems are difficult to solve,
but I've always found that having a good basic understanding, checking
logs, using tools to confirm what is happening, and doing research on
how things work, allows me to solve those problems eventually.

Not so with CUPS and printing.  I have tried many different approaches
(e.g. * reinstall from scratch, accept the default packages and default
options.  * go to the linux printing site and follow the recommended
method for my model of printer * try to understand how CUPS works, set
up as statically and simply as possible, and use standard tools to
troubleshoot printing failures.)  I have not succeeded with any approach.

It could be that I have struck certain models of printer with bugs. 
Hardware and firmware bugs exist, and not just in printers.  However, I
don't find hardware or firmware bugs cause me significant pain as there
are normally software or configuration based work-arounds/allowances for
them in Debian. Except for printers.  These same printer models work
much more reliably in MacOS and Windows.

Back in the lpr/lpd days things were more reliable.

Is there a deeper problem affecting printing on linux?  I asked work
colleagues and got two responses:

"oh, shit.  you’re actually printing from linux.  my condolences.', and

"I use Epson and Ubuntu, never had an issue with print over IP - so I
can attest to drivers working from that perspective atleast"

My perspective is that there is a significant issue, at least for a
portion of users.

Implying the user is at fault (which Brian isn't necessarily doing
here,) or acting surprised when someone has trouble printing, is like
gaslighting.  Maybe it works OK for you, but please understand that is
not the general case.  Debian can't support every printer for every
user, but knowing that, CUPS should come with a health warning:  "We
supply this software as-is in the knowledge that it has known faults,
and will not work reliably for all users.  We wish there were a way that
Debian users could reliably print, but there is not.  You may get some
help on Debian User, but in general printing is not supported."

Thanks,
Alex

[David]

On Sun, 2023-05-07 at 11:02 +1200, Alex King wrote:
> Printing on Linux is poor.  CUPS is poor.  It doesn't work for some
> (a
> lot?) of people.

I bought an Epson WF-C5290 18 months ago, connected it up, installed
the Linux driver provided on the Epson site, and it has been as solid
as a rock.
Very happy with it.
Cheers!

<snip>

--
A Kiwi in Australia,
doing my bit toward raising the national standard.

[Byung-Hee HWANG]

Alex King <al...@king.net.nz> writes:

> Printing on Linux is poor.  CUPS is poor.  It doesn't work for some (a lot?)
> of people.
>
> I have a Brother HL-L2300D printer.  It is connected to my (Debian bullseye)
> workstation by USB.  I have CUPS installed.

> (...)

Hellow Alex!

In South Korea, most people does printing at just MS-Windows machine. Me
too. So i have no printer in house. If i have to print something, i go
to my friend home -- he have printer and MS-Windows machine.

Maybe off-topic, have nice day ^^^


Sincerely, Byung-Hee from South Korea

--
^고맙습니다 _布德天下_ 감사합니다_^))//

[Charlie Gibbs]

On Sat May 6 21:11:09 2023 Alex King <al...@king.net.nz> wrote:

> Printing on Linux is poor.  CUPS is poor.  It doesn't work for some (a
> lot?) of people.
>
> I have a Brother HL-L2300D printer.  It is connected to my (Debian
> bullseye) workstation by USB.  I have CUPS installed.
>

> My printer prints sometime.  Other times, it spins up (makes a noise
> like it is about to start printing), but nothing comes out. I can't
> get any useful diagnostics to tell me where the problem might be.
>
> My parents, who live some distance away have an HP inkjet printer.
> It works sometimes.  Other times it doesn't.  I get it set up so it's
> working and it might work for a while, but it will stop working for
> no reason.

<snip>

I've managed to get CUPS working reasonably well, although occasionally
I lose the ability to print. Although I don't have a permanent fix,
going into CUPS by pointing a web browser at localhost:631, removing
the printer, and adding it back in gets things going again. My printer
is connected via Ethernet; I suspect that power outages might cause
DHCP to give it a different IP address when it comes back up, and CUPS
gets confused.

Since you 're using a USB connection, this might not help you - but you
might try removing and re-adding the printer anyway.

--
/~\ Charlie Gibbs | Life is perverse.
\ / <cgi...@kltpzyxm.invalid> | It can be beautiful -
X I'm really at ac.dekanfrus | but it won't.
/ \ if you read it the right way. | -- Lily Tomlin

[Eduardo M KALINOWSKI]

On 06/05/2023 20:02, Alex King wrote:
> Implying the user is at fault (which Brian isn't necessarily doing
> here,) or acting surprised when someone has trouble printing, is like
> gaslighting.  Maybe it works OK for you, but please understand that is
> not the general case.

Take not of this, it'll be important later.

> Debian can't support every printer for every
> user, but knowing that, CUPS should come with a health warning:  "We
> supply this software as-is in the knowledge that it has known faults,
> and will not work reliably for all users.  We wish there were a way that
> Debian users could reliably print, but there is not.  You may get some
> help on Debian User, but in general printing is not supported."

This proposal is as bad as what you criticized in the first quoted
segment. It might say the opposite, but it's still an overly wide
generalization.

Pretty much everything in Debian is provided as-is and with no
warranties (it's explicitly said so in the license), but the maintainers
do try to make the software work as well as possible (and other people
can step in if the maintainer is unresponsive).

Since we're talking about anecdotes, I have a very similar printer to
yours (a Brother MF-2470DW - I believe the engine is basically the same,
but my model has a scanner and maybe fax), and I've used it with cups
with no issues for years, both with the Brother proprietary driver and
lately with the "driverless" feature (which should really be called
"universal driver" or something like that, but that's another issue).
Before that, I've had at least three other printers (Lexmark, HP and one
that I can't remember) that also worked with no problems. This doesn't
prove anything, but neither do your bad experiences.

I'd guess that more people can print than can't (provided the printer is
supported), so even if "cups works fine and printing is supported" isn't
always correct, it's probably more correct than "in general printing is
not supported".


--
Not everything worth doing is worth doing well.

Eduardo M KALINOWSKI
edu...@kalinowski.com.br

[gene heskett]

On 5/6/23 19:29, Alex King wrote:
> Printing on Linux is poor.  CUPS is poor.  It doesn't work for some (a
> lot?) of people.
>
> I have a Brother HL-L2300D printer.  It is connected to my (Debian
> bullseye) workstation by USB.  I have CUPS installed.
>
> My printer prints sometime.  Other times, it spins up (makes a noise
> like it is about to start printing), but nothing comes out. I can't get
> any useful diagnostics to tell me where the problem might be.
>

There is a light at the end of this dark tunnel, IF you are willing to
change the brand name on the printer. But in your case you've already
done that. So now do a search for brotherusa, go there and download
their driver installer, unpack it, run it sudo if needed. It will ask
you for the model # of your printer, enter it EXACTLY, the script will,
if you've net access, goto brothers site, download the exact driver your
printer needs, install it, integrating with cups perfectly but you will
probably need to disable cups-browsed as it will make the default driver
the everywhere driver, crippling 95% of the printers abilities. And
from the machine the printer is plugged into, and assuming browsed is
stopped so you can use the brother driver, it Just Works.

However, if its to be shared, usable from other machines on your local
home network AND your other machines are also running bullseye, and some
of my arm stuff is, something is locking out the discovery of shares by
cups, hence my constant harping about it here. Other Buster machines
Just Work but in my case and to emphasize the point, an rpi4b running
buster works but no banana pi m2 running bullseye can find a printer for
cups. But lpstat -t on that same bpi running bullseye sees them all.

I assume they can print, but thru an lp derivitive that means your Aunt
Tilly has to remember the exact name and all the options that go with
it. And Aunt Tilly will be back on windows next week. She, like I, just
wants HER printer to work.

> My parents, who live some distance away have an HP inkjet printer.  It
> works sometimes.  Other times it doesn't.  I get it set up so it's
> working and it might work for a while, but it will stop working for no
> reason.  There might be several queues for the printer; some work and
> some just don't.  A working queue will stop working for no discernible
> reason.  Working queues will disappear, new queues will appear seemingly
> at random.  The print system will default to an automatically provided
> queue that could never work, because it relies on some software
> component that is not installed.... etc... etc...
>
> Between my parents and my own system, I have spent 10s or 100s of hours
> trying to get a reliable printing system over decades, with many
> different printers.  Maybe there were periods where printing worked OK.
> But I haven't managed to achieve reliable printing in the medium term.
>
> I read ESR https://www.catb.org/~esr/writings/cups-horror.html, and my
> personal experience is that nothing much has changed in the "driverless"
> era.

To me, its been a wholesale slauterhouse since cups was sold to Apple.
The only fix I can see will require that we as a world wide group,
decide to monetarily support a cups like fork, getting away from the if
it doesn't suit Apple, it doesn't happen, influence. TANSTAAFL folks.
If you think the peanuts are free, its time to look at the price of the
beer. Coders like to eat, good ones should be able to afford a longer
ladder up the side of the hog... I can easily afford a $25/anum fee.
What say you?

> I've been a sysadmin for 30 odd years, configuring different aspects of
> linux (webservers, email servers, DNS, networking, desktop environments
> etc.) using open source software.  Some problems are difficult to solve,
> but I've always found that having a good basic understanding, checking
> logs, using tools to confirm what is happening, and doing research on
> how things work, allows me to solve those problems eventually.

And I've been roping electrons into doing useful work for about 75 years.

> Not so with CUPS and printing.  I have tried many different approaches
> (e.g. * reinstall from scratch, accept the default packages and default
> options.  * go to the linux printing site and follow the recommended
> method for my model of printer * try to understand how CUPS works, set
> up as statically and simply as possible, and use standard tools to
> troubleshoot printing failures.)  I have not succeeded with any approach.

ditto.

>
> It could be that I have struck certain models of printer with bugs.
> Hardware and firmware bugs exist, and not just in printers.  However, I
> don't find hardware or firmware bugs cause me significant pain as there
> are normally software or configuration based work-arounds/allowances for
> them in Debian. Except for printers.  These same printer models work
> much more reliably in MacOS and Windows.
>
> Back in the lpr/lpd days things were more reliable.
>

They apparently still are, for those with the memory for cli.

> Is there a deeper problem affecting printing on linux?  I asked work
> colleagues and got two responses:
>
> "oh, shit.  you’re actually printing from linux.  my condolences.', and
>
> "I use Epson and Ubuntu, never had an issue with print over IP - so I
> can attest to drivers working from that perspective atleast"
>
> My perspective is that there is a significant issue, at least for a
> portion of users.
>
> Implying the user is at fault (which Brian isn't necessarily doing
> here,) or acting surprised when someone has trouble printing, is like
> gaslighting.  Maybe it works OK for you, but please understand that is
> not the general case.  Debian can't support every printer for every
> user, but knowing that, CUPS should come with a health warning:  "We
> supply this software as-is in the knowledge that it has known faults,
> and will not work reliably for all users.  We wish there were a way that
> Debian users could reliably print, but there is not.  You may get some
> help on Debian User, but in general printing is not supported."
>
> Thanks,
> Alex
>
> On 6/05/23 05:45, Brian wrote:
>> Your conclusion is that the printing system is in itself is defective
>> and that is
>> reflected in your response.

No adverse reflection on Brian, he has been very helpful indeed in
isolating my problems to a broken cups. But neither of us has yet found
whats actually broken.

Take care & stay well everybody.

[Brian]

Please give 'lpstat -t' for bpi51 (bullseye) and a buster machine.

Applle ceased any involvement with CUPS development and parted company with
its Chief Printing Engineer a number of years ago. Debian CUPS is produced
by a team led by the creator of CUPS. Your requested fix is in place :).

--
Brian.

[Eduardo M KALINOWSKI]

On 07/05/2023 12:26, gene heskett wrote:
> There is a light at the end of this dark tunnel, IF you are willing to
> change the brand name on the printer. But in your case you've already
> done that.  So now do a search for brotherusa, go there and download
> their driver installer, unpack it, run it sudo if needed. It will ask
> you for the model # of your printer, enter it EXACTLY, the script will,
> if you've net access, goto brothers site, download the exact driver your
> printer needs, install it, integrating with cups perfectly but you will
> probably need to disable cups-browsed as it will make the default driver
> the everywhere driver, crippling 95% of the printers abilities.  And
> from the machine the printer is plugged into, and assuming browsed is
> stopped so you can use the brother driver, it Just Works.

Please stop spreading misinformation. I have a Brother MFC-L2740DW
(which I believe is the exact model you have, or if not very similar)
and it works perfectly with the "driverless" approach, both with the
cups ppd generator (everywhere) and the cups-filters pps generator
(driverless). The first one leads to slow printing for some reason, and
I had to select "high" quality to get standard quality; the second one
is as fast as the proprietary driver. Auto discovery with cups-browsed
also works. There might be some specialized options only available in
the proprietary driver, but everything needed for general use (tray
selection, duplex, etc) is available in the driverless driver.

The proprietary driver is fine and works well, if it suits you, feel
free to use it. Just be aware that it's only available for i386, not
amd64, so in a desktop pc you'll need to add the i386 architecture. On a
Raspberry Pi or other arm computer you won't be able to run the
proprietary driver.

But please don't say it's the only option because you've been unable to
use the other ones.

--
Ban the bomb. Save the world for conventional warfare.

Eduardo M KALINOWSKI
edu...@kalinowski.com.br

[gene heskett]

gene@bpi51:~$ lpstat -t
scheduler is running
system default destination: PDF
device for HLL2320D-RAW: ipp://192.168.71.3:631/printers/HLL2320D
device for PDF: cups-pdf:/
HLL2320D-RAW accepting requests since Mon 01 May 2023 04:29:40 PM -05
PDF accepting requests since Fri 02 Dec 2022 11:13:10 PM -05
printer HLL2320D-RAW is idle. enabled since Mon 01 May 2023 04:29:40 PM -05
printer PDF is idle. enabled since Fri 02 Dec 2022 11:13:10 PM -05

That's new, but the other bigger mfc inkjet is missing, so I went to the
ff screen, opened a tab and sent it to localhost:631, cups was running,
clicking on printers got me only the local pdf generator. I didn't
disturb it further as its driving a 3d printer, has ben since the wether
cleared about 17:00 and will be busy doing that till around 13:00
tomorrow. making a pair of half-nuts for a woodworkers big leg vise,
with a 24" long, 2" in diameter hard maple screw I designed for my own
workbench. But I thought I might see if I could sell a dozen or so once
I had it working. Unforch, and the driving force behind my building a
printer farm, is the 3 weeks it takes to print the rest of it after I've
made the screw on one of my milling machines, using gcode I wrote.
That machine, bpi51, did not get updated friday because it was busy
driving a printer.

bpi54, which is an identical bpi, is running with nother but a bare btt
octopus-pro board, did get an update friday which included a new avahi.

gene@bpi54:~$ lpstat -t
scheduler is running
no system default destination
device for Brother_HL-L2320D_series:
usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
device for Brother_MFC-J6920DW_photo:
usb://Brother/MFC-J6920DW?serial=BROG5F229909
device for HLL2320D: usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
device for MFCJ6920DW: usb://Brother/MFC-J6920DW?serial=BROG5F229909
Brother_HL-L2320D_series accepting requests since Thu 04 May 2023
06:24:04 AM EDT
Brother_MFC-J6920DW_photo accepting requests since Thu 30 Mar 2023
09:16:43 AM EDT
HLL2320D accepting requests since Thu 04 May 2023 06:24:04 AM EDT
MFCJ6920DW accepting requests since Sun 26 Mar 2023 03:30:13 PM EDT
printer Brother_HL-L2320D_series is idle. enabled since Thu 04 May 2023
06:24:04 AM EDT
printer Brother_MFC-J6920DW_photo is idle. enabled since Thu 30 Mar
2023 09:16:43 AM EDT
printer HLL2320D is idle. enabled since Thu 04 May 2023 06:24:04 AM EDT
printer MFCJ6920DW is idle. enabled since Sun 26 Mar 2023 03:30:13 PM EDT

as can be seen from its "lpstat -t" it shows all shares, but cups still
can't see anything. I'm not sure if the pdf generator is installed
[...]

>> To me, its been a wholesale slauterhouse since cups was sold to Apple.
>> The only fix I can see will require that we as a world wide group, decide to
>> monetarily support a cups like fork, getting away from the if it doesn't
>> suit Apple, it doesn't happen, influence. TANSTAAFL folks. If you think the
>> peanuts are free, its time to look at the price of the beer. Coders like to
>> eat, good ones should be able to afford a longer ladder up the side of the
>> hog... I can easily afford a $25/anum fee.
>> What say you?
>

> Apple ceased any involvement with CUPS development and parted company with

> its Chief Printing Engineer a number of years ago. Debian CUPS is produced
> by a team led by the creator of CUPS. Your requested fix is in place :).

If so, (this is the first I've heard of it, and I've only known Michael
since the late 1980's when we were both heavily involved in the os9
development, a mini unix that ran of the trs-80 color computers) where
do I email now to be assured Michael will see it? Is there a new cups
mailing list?

Do you have any idea if that fix will be released for arm64 bullseye? I
just checked bpi54, no updates available since the Friday update. Ditto
for the intel busters here, but they're busters, so don't need the fix,
they Just Work.

Thanks Brian, take care and stay well.

[gene heskett]

On 5/7/23 13:34, Eduardo M KALINOWSKI wrote:
> On 07/05/2023 12:26, gene heskett wrote:
>> There is a light at the end of this dark tunnel, IF you are willing to
>> change the brand name on the printer. But in your case you've already
>> done that.  So now do a search for brotherusa, go there and download
>> their driver installer, unpack it, run it sudo if needed. It will ask
>> you for the model # of your printer, enter it EXACTLY, the script
>> will, if you've net access, goto brothers site, download the exact
>> driver your printer needs, install it, integrating with cups perfectly
>> but you will probably need to disable cups-browsed as it will make the
>> default driver the everywhere driver, crippling 95% of the printers
>> abilities.  And from the machine the printer is plugged into, and
>> assuming browsed is stopped so you can use the brother driver, it Just
>> Works.
>
> Please stop spreading misinformation. I have a Brother MFC-L2740DW
> (which I believe is the exact model you have, or if not very similar)

I doubt it, does your handle tabloid sized paper (11x17"), including the
scanner in its lid with an adf? Does it have 2 paper drawers?

> and it works perfectly with the "driverless" approach, both with the
> cups ppd generator (everywhere) and the cups-filters pps generator
> (driverless). The first one leads to slow printing for some reason, and
> I had to select "high" quality to get standard quality; the second one
> is as fast as the proprietary driver. Auto discovery with cups-browsed
> also works. There might be some specialized options only available in
> the proprietary driver, but everything needed for general use (tray
> selection, duplex, etc) is available in the driverless driver.

You just showed that it doesn't Just Work, which is exactly why I run
the brother drivers, which run just fine on a 6 core i5. Every feature
this printer has, I can adjust from the cups menu's. The driverless
setup can run this inkjet, w/o duplex because its w/o tray selection,
printing everything on paper from the top smaller tray normally loaded
with 50 cents a sheet glossy photo paper.

> The proprietary driver is fine and works well, if it suits you, feel
> free to use it. Just be aware that it's only available for i386, not
> amd64, so in a desktop pc you'll need to add the i386 architecture. On a
> Raspberry Pi or other arm computer you won't be able to run the
> proprietary driver.

An arm computer has no need to run their driver, and yes, the rpi4b
running 1500 lbs worth of 80 yo Sheldon lathe, but running buster sees 7
shared printers from this machine right now. And they are all usable
from that keyboard.

If their driver ever had an i386 limitation its news to me.

> But please don't say it's the only option because you've been unable to
> use the other ones.

This printer also has a cat5 feed, with an address in my local
192,168,xx, block, so even if its not plugged into a given machine, but
the printer and the scanner should still be available at it ipv4
address. That should be found by cups running anywhere on the property,
it is not discovered. But I'm mistaken, I now recall unplugging the cat
5 cable about 2 years ago. USB is faster at data transfer. By about 5x.

[Brian]

On Mon 08 May 2023 at 00:23:43 -0400, gene heskett wrote:

> On 5/7/23 12:48, Brian wrote:

[...]

> > Please give 'lpstat -t' for bpi51 (bullseye) and a buster machine.

> gene@bpi51:~$ lpstat -t
> scheduler is running
> system default destination: PDF
> device for HLL2320D-RAW: ipp://192.168.71.3:631/printers/HLL2320D
> device for PDF: cups-pdf:/

Thanks.

'lpstat -t' only ever shows *local* printers. That is, printers that have
been set up (manually in this case) on the local machine. It will never
discover and show printers on the network. This was mentioned earlier in
this thread, but you do not appear to appreciate its significance.

To be clear: HLL2320D-RAW and PDF are local printers. We set up HLL2320D-RAW
(which is a working printer) togetger. Should you wish to see *all* devices
(local and on the network) us

lpstat -e
lpstat -l -e

The second command was explained earlier in the thread.

[...]

> gene@bpi54:~$ lpstat -t
> scheduler is running
> no system default destination
> device for Brother_HL-L2320D_series:
> usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
> device for Brother_MFC-J6920DW_photo:
> usb://Brother/MFC-J6920DW?serial=BROG5F229909
> device for HLL2320D: usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
> device for MFCJ6920DW: usb://Brother/MFC-J6920DW?serial=BROG5F229909

These are the local printers on bpi54. All connected by USB. All set up by
you and all working

Summary: Everything is as it should be.

Your first mail has:

> All of my bullseye machines are locked out, printer screen at
> localhost:631 is empty, and no printers can be found and added.
>
> But open a shell, and type "lpstat -t" and it gets the full list of
> available printers on that same bullseye machine whose cups output is
> empty.

The facts as expressed are OK. Your interpretation of them is sub-optimal.
A lack of understanding about what localhost:631 and 'lpstat -t' show is
the root of problem and colours everything you have written here..

[...]

> > Apple ceased any involvement with CUPS development and parted company with
> > its Chief Printing Engineer a number of years ago. Debian CUPS is produced
> > by a team led by the creator of CUPS. Your requested fix is in place :).
>
> If so, (this is the first I've heard of it, and I've only known Michael
> since the late 1980's when we were both heavily involved in the os9
> development, a mini unix that ran of the trs-80 color computers) where do I
> email now to be assured Michael will see it? Is there a new cups mailing
> list?

Please see our wiki.

> Do you have any idea if that fix will be released for arm64 bullseye? I just
> checked bpi54, no updates available since the Friday update. Ditto for the
> intel busters here, but they're busters, so don't need the fix, they Just
> Work.

I haven't a clue about arm64. I am not even sure that CUPS is the issue. You
have a classical local printer set up. It works. There are three other printers
that could be set up with the same technique. Remenber - you are the one who
does not want a New Architecture setup.

--
Brian.

[gene heskett]

On 5/8/23 07:49, Brian wrote:
> On Mon 08 May 2023 at 00:23:43 -0400, gene heskett wrote:
>
>> On 5/7/23 12:48, Brian wrote:
>
> [...]
>
>>> Please give 'lpstat -t' for bpi51 (bullseye) and a buster machine.
>
>> gene@bpi51:~$ lpstat -t
>> scheduler is running
>> system default destination: PDF
>> device for HLL2320D-RAW: ipp://192.168.71.3:631/printers/HLL2320D
>> device for PDF: cups-pdf:/
>
> Thanks.
>
> 'lpstat -t' only ever shows *local* printers. That is, printers that have
> been set up (manually in this case) on the local machine. It will never
> discover and show printers on the network. This was mentioned earlier in
> this thread, but you do not appear to appreciate its significance.
>
> To be clear: HLL2320D-RAW and PDF are local printers. We set up HLL2320D-RAW
> (which is a working printer) togetger. Should you wish to see *all* devices
> (local and on the network) us
>
> lpstat -e
> lpstat -l -e
>

Aha! now the two bpi's see all shares, + add the pdf generator if its
installed. The HLL2320D as seen by -t, is the result of our earlier
test, it actually added the printer to the local lp world. But not to cups.

I'll update bpi51 when the current part is finished, probably about an
hour yet.

Thanks Brian.

The big inkjet is well over 5 years old, and among other things the New
Architecture does not recognize is it has two trays for paper source,
always using the $0.12 a sheet glossy photo from the top tray.

Imagine what it would cost me to print all 1330 some pages of the
current linuxcnc user docs. Not to mention I'd have to reload that
smaller tray about 14 times. Tain't gonna happen.

And my ISP is having email probs its Monday.
>

Cheers, Gene Heskett.
--

[gene heskett]

And that updated 77 pkgs, but did not require a reboot. And no pkg
changed anything about the cups blank printers discovered screen at
localhost:631.

And its back to making another part. Busy till around 2am local

Thanks Brian.
>
>> The second command was explained earlier in the thread.
>>
>> [...]
>>
>>> gene@bpi54:~$ lpstat -t
>>> scheduler is running
>>> no system default destination
>>> device for Brother_HL-L2320D_series:
>>> usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
>>> device for Brother_MFC-J6920DW_photo:
>>> usb://Brother/MFC-J6920DW?serial=BROG5F229909
>>> device for HLL2320D:
>>> usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
>>> device for MFCJ6920DW: usb://Brother/MFC-J6920DW?serial=BROG5F229909
>>
>> These are the local printers on bpi54. All connected by USB. All set
>> up by
>> you and all working
>>
>> Summary: Everything is as it should be.
>>
>> Your first mail has:
>>
>>    > All of my bullseye machines are locked out, printer screen at
>>    > localhost:631 is empty, and no printers can be found and added.

You are missing the point, lpstat is seeing them, but cups is not.
That it seems to me, s/b where we should be concentrating our discovery
efforts. FWIW reinstalling cups and cups-browsed has been done, made no
difference that I could detect. Is there something I could put at the
top of /etc/cups/cupsd.conf to make any failures or rejects generate
meaningful msgs in /var/log/cups/error_log?

Took them till close to noon to find it.

Thanks Brian.

[gene heskett]

On 5/8/23 07:49, Brian wrote:

> On Mon 08 May 2023 at 00:23:43 -0400, gene heskett wrote:
>

Brian, I found the secret sauce. Armed with the knowledge that Mike had
moved, I found his new site, and found the answer in 5 minutes under the
"printer sharing" link. Something is broken when using a client.conf
that contains the ServerName directive as it does not work from a
hostname file lookup, but does work if the ServerName is the ipv4
address:631

Possibly the result of my system not having a working dhcpd except the
relay in the router to my isp's dns.

I think you have said resolv.conf Search directive doesn't work but
nsswitch.conf was mentioned and there is a diff between this machine and
one of the arms. So what do I put in nsswitch.conf to make cups search
the hosts file first?

I think that, with some PEBKAC has been the problem all along.

Thanks Brian, take care & stay well.

Cheers, Gene Heskett.
--

[Greg Wooledge]

On Tue, May 09, 2023 at 04:06:14AM -0400, gene heskett wrote:
> I think you have said resolv.conf Search directive doesn't work but
> nsswitch.conf was mentioned and there is a diff between this machine and one
> of the arms. So what do I put in nsswitch.conf to make cups search the hosts
> file first?

The bare minimum would be:

hosts: files dns

Mine contains this:

hosts: files mdns4_minimal [NOTFOUND=return] dns


The "search" directive in /etc/resolv.conf is followed by a space-separated
list of domain names. Yours should say:

search coyote.den

[gene heskett]

On 5/9/23 07:12, Greg Wooledge wrote:
> On Tue, May 09, 2023 at 04:06:14AM -0400, gene heskett wrote:
>> I think you have said resolv.conf Search directive doesn't work but
>> nsswitch.conf was mentioned and there is a diff between this machine and one
>> of the arms. So what do I put in nsswitch.conf to make cups search the hosts
>> file first?
>
> The bare minimum would be:
>
> hosts: files dns
>
> Mine contains this:
>
> hosts: files mdns4_minimal [NOTFOUND=return] dns

and my bpi54 is:
hosts: files mymachines dns myhostname

>
> The "search" directive in /etc/resolv.conf is followed by a space-separated
> list of domain names. Yours should say:
>
> search coyote.den

aha! again: was:
nameserver 192.168.71.1
search hosts,nameserver
Which is not space separated, thank you, I've got it fixed in 2 places
now. I think.

[Brian]

On Tue 09 May 2023 at 16:49:22 -0400, gene heskett wrote:

> On 5/9/23 07:12, Greg Wooledge wrote:
> > On Tue, May 09, 2023 at 04:06:14AM -0400, gene heskett wrote:
> > > I think you have said resolv.conf Search directive doesn't work but
> > > nsswitch.conf was mentioned and there is a diff between this machine and one
> > > of the arms. So what do I put in nsswitch.conf to make cups search the hosts
> > > file first?
> >
> > The bare minimum would be:
> >
> > hosts: files dns
> >
> > Mine contains this:
> >
> > hosts: files mdns4_minimal [NOTFOUND=return] dns
> and my bpi54 is:
> hosts: files mymachines dns myhostname

bpi54 has two printers attached by USB. It also hosts four print queues that work
from bpi54 and bpi51. You have a printing system that should continue working
until trixie comes along. Then it will fall apart.

So why this descent into GNU Name Service Switch (NSS) functionality when you are
satisfied with the printing situation?

Greg Wooledge's nsswitch.conf line is what would be expected on a machine having
avahi-demon.service. You do not have avahi-daemon and libnss-mdns installed. That
is fine. A descision has been made to create queues with vendor drivers on bpi54
manually.

Your nsswitch.conf line implies libnss-mymacines and libnss-mymhostname are used.
They have man pages to help you decide what parts they play on bpi54.

What do you have on bpi51?

--
Brian.

[gene heskett]

They were not installed, and neither are 95% of the manpages. man-db is
installed, pinfo is installed, neither has any knowledge of the missing
man pages.

>
> What do you have on bpi51?

bpi51 is busy, so bpi54 is being used, same iso installed both.

Man pages apparently are one of armbian's casualties. And avahi* and
cups-browsed has been reinstalled. When I went to bed last night, the
printers were being listed on the localhost:631/printers screen IF there
is an /etc/cups/client,conf containing the IP address:port of the shared
printers, but disappears if the machine name is used, And w/o manpages
it was not possible to find out that resolv.conf was using space
separated names and I had comma separated them. Fixed now.
>
Also on the bpi's, running armbian, libnss-ldap is installed, which
conflicts with installing libnss-*, but did install libnss-my*, and now
the printers have disappeared again. That does not hold water. What the
heck is going on now?

doing a status request on the cups stuff shows that systemd restarted
cups and nearly everything else I just checked, a few seconds after
midnight last night, and now cups at localhost:631/printers is using a
white cane again.


Thanks Brian. Take care & stay well.

[to...@tuxteam.de]

On Wed, May 10, 2023 at 10:04:47AM -0400, gene heskett wrote:
> On 5/10/23 08:17, Brian wrote:

[...]

> > Your nsswitch.conf line implies libnss-mymacines and libnss-mymhostname are used.
> > They have man pages to help you decide what parts they play on bpi54.
>
> They were not installed, and neither are 95% of the manpages. man-db is
> installed, pinfo is installed, neither has any knowledge of the missing man
> pages.

...but by now, you might know the trick:

apt-file search libnss | grep man

leads you to the packages "libnss-myhostname" and "libnss-mymachine" containing
them.

Cheers
--
t

[Brian]

On Wed 10 May 2023 at 10:04:47 -0400, gene heskett wrote:

> On 5/10/23 08:17, Brian wrote:

[...]

> > Your nsswitch.conf line implies libnss-mymacines and libnss-mymhostname are used.
> > They have man pages to help you decide what parts they play on bpi54.
>
> They were not installed, and neither are 95% of the manpages. man-db is
> installed, pinfo is installed, neither has any knowledge of the missing man
> pages.

dpkg -L libnss-mymacines
man nss-myhostname

> > What do you have on bpi51?
>
> bpi51 is busy, so bpi54 is being used, same iso installed both.

The same iso does not mean nsswitch.conf is the same on both. In fact, I think
they are not identical.

> Man pages apparently are one of armbian's casualties. And avahi* and
> cups-browsed has been reinstalled. When I went to bed last night, the
> printers were being listed on the localhost:631/printers screen IF there is
> an /etc/cups/client,conf containing the IP address:port of the shared
> printers, but disappears if the machine name is used, And w/o manpages it
> was not possible to find out that resolv.conf was using space separated
> names and I had comma separated them. Fixed now.

Is /etc/cups/client,conf really, really needed?

> Also on the bpi's, running armbian, libnss-ldap is installed, which
> conflicts with installing libnss-*, but did install libnss-my*, and now the
> printers have disappeared again. That does not hold water. What the heck is
> going on now?

I haven't any idea and do not claim the know anything about armbian and how
it should deal with NSS.

> doing a status request on the cups stuff shows that systemd restarted cups
> and nearly everything else I just checked, a few seconds after midnight last
> night, and now cups at localhost:631/printers is using a white cane again.

The scheduler restarts itself every 24 hours.

--
Brian.

[gene heskett]

On 5/10/23 11:29, Brian wrote:
> On Wed 10 May 2023 at 10:04:47 -0400, gene heskett wrote:
>
>> On 5/10/23 08:17, Brian wrote:
>
> [...]
>
>>> Your nsswitch.conf line implies libnss-mymacines and libnss-mymhostname are used.
>>> They have man pages to help you decide what parts they play on bpi54.
>>
>> They were not installed, and neither are 95% of the manpages. man-db is
>> installed, pinfo is installed, neither has any knowledge of the missing man
>> pages.
>
> dpkg -L libnss-mymacines
> man nss-myhostname
>
>>> What do you have on bpi51?
>>
>> bpi51 is busy, so bpi54 is being used, same iso installed both.
>
> The same iso does not mean nsswitch.conf is the same on both. In fact, I think
> they are not identical.
>
>> Man pages apparently are one of armbian's casualties. And avahi* and
>> cups-browsed has been reinstalled. When I went to bed last night, the
>> printers were being listed on the localhost:631/printers screen IF there is
>> an /etc/cups/client,conf containing the IP address:port of the shared
>> printers, but disappears if the machine name is used, And w/o manpages it
>> was not possible to find out that resolv.conf was using space separated
>> names and I had comma separated them. Fixed now.
>
> Is /etc/cups/client,conf really, really needed?
>

That is the first thing cups docs tell you to do, see "printer sharing"

>> Also on the bpi's, running armbian, libnss-ldap is installed, which
>> conflicts with installing libnss-*, but did install libnss-my*, and now the
>> printers have disappeared again. That does not hold water. What the heck is
>> going on now?
>
> I haven't any idea and do not claim the know anything about armbian and how

> it should deal with NSS\


Since that comes from a debian arm64 repo. my first assumption is that
its identical.

>> doing a status request on the cups stuff shows that systemd restarted cups
>> and nearly everything else I just checked, a few seconds after midnight last
>> night, and now cups at localhost:631/printers is using a white cane again.
>
> The scheduler restarts itself every 24 hours.
>

Now, since my post earlier this morning, I restarted cups, no diff, Set
reporting to debug, now getting 20k of noise in the error_log per
disturbance. It claims that anytime it encounters the Server, this
machine, that it cannot assign the address, but doesn't say why. Does
that tell you anything. I will bump the debug to debug2 which logs
everything. After lunch and a nap before I tackle a milling machine with
a shorted home switch.

[Brian]

On Wed 10 May 2023 at 13:18:07 -0400, gene heskett wrote:

> On 5/10/23 11:29, Brian wrote:
> > On Wed 10 May 2023 at 10:04:47 -0400, gene heskett wrote:
> >
> > > On 5/10/23 08:17, Brian wrote:
>
> > [...]

> > Is /etc/cups/client,conf really, really needed?
> >
> That is the first thing cups docs tell you to do, see "printer sharing"

A link would be ever so useful.

> > > Also on the bpi's, running armbian, libnss-ldap is installed, which
> > > conflicts with installing libnss-*, but did install libnss-my*, and now the
> > > printers have disappeared again. That does not hold water. What the heck is
> > > going on now?
> >
> > I haven't any idea and do not claim the know anything about armbian and how
> > it should deal with NSS\
>
> Since that comes from a debian arm64 repo. my first assumption is that its
> identical.

After appreciating that bpi51 has libnss-mdns installed, you might discard any
assumption that nsswitch.conf on bpi54 has the same contents.

--
Brian.

[gene heskett]

I don't believe any of these 4 bpi's have libnss-mdns installed, locate
after a sudo updatedb, cannot find it on either of the 2 that are live
on this net ATM.

Now. I modified /etc/cups/cupsd.conf to change loglevel to debug2, and
add Listen 192.168.xx.yy:631, then restarted cups, getting this notice
in /var/log/cups/error_log:

E [10/May/2023:14:32:16 -0500] Unable to open listen socket for address
[v1.::1]:631 - Cannot assign requested address.

E [10/May/2023:14:32:16 -0500] Unable to open listen socket for address
192.168.xx.yy:631 - Cannot assign requested address.

There's no ipv6 here, none within 100 miles so the first is expected but
what is the second one telling us? Permissions, bad path, wrong time of
the month? IDK...

This above is on bpi51.

Take care & stay well Brian.

[gene heskett]

On 5/10/23 14:22, Brian wrote:
> On Wed 10 May 2023 at 13:18:07 -0400, gene heskett wrote:
>
>> On 5/10/23 11:29, Brian wrote:
>>> On Wed 10 May 2023 at 10:04:47 -0400, gene heskett wrote:
>>>
>>>> On 5/10/23 08:17, Brian wrote:
>>
>>> [...]
>
>>> Is /etc/cups/client,conf really, really needed?
>>>
>> That is the first thing cups docs tell you to do, see "printer sharing"
>
> A link would be ever so useful.

send browser to cups.org, click help, in right pane, click "printer
sharing", scroll down about a screenfull to Automatic using IPP

>
>>>> Also on the bpi's, running armbian, libnss-ldap is installed, which
>>>> conflicts with installing libnss-*, but did install libnss-my*, and now the
>>>> printers have disappeared again. That does not hold water. What the heck is
>>>> going on now?
>>>
>>> I haven't any idea and do not claim the know anything about armbian and how
>>> it should deal with NSS\
>>
>> Since that comes from a debian arm64 repo. my first assumption is that its
>> identical.
>
> After appreciating that bpi51 has libnss-mdns installed, you might discard any
> assumption that nsswitch.conf on bpi54 has the same contents.
>

[debia...@howorth.org.uk]

gene heskett <ghes...@shentel.net> wrote:
> On 5/10/23 14:22, Brian wrote:
> > A link would be ever so useful.
>
> send browser to cups.org, click help, in right pane, click "printer
> sharing", scroll down about a screenfull to Automatic using IPP

So the answer to Brian's question is
https://www.cups.org/doc/sharing.html and scroll down about a screenful
to Automatic Configuration using IPP

I think :)

[Brian]

On Wed 10 May 2023 at 15:51:53 -0400, gene heskett wrote:

> On 5/10/23 14:22, Brian wrote:

[...]

> > After appreciating that bpi51 has libnss-mdns installed, you might discard any
> > assumption that nsswitch.conf on bpi54 has the same contents.
> >
> I don't believe any of these 4 bpi's have libnss-mdns installed, locate
> after a sudo updatedb, cannot find it on either of the 2 that are live on
> this net ATM.

bpi51 has avahi-browse. avahi-browse depends on avahi-daemon. avahi-daemon
recommends libnss-mdns.

> Now. I modified /etc/cups/cupsd.conf to change loglevel to debug2, and add
> Listen 192.168.xx.yy:631, then restarted cups, getting this notice in
> /var/log/cups/error_log:

This is on bpi54? I do not believe a change to /etc/cups/cupsd.conf is
necessary.

--
Brian.

[Brian]

On Wed 10 May 2023 at 16:02:43 -0400, gene heskett wrote:

> On 5/10/23 14:22, Brian wrote:
> > On Wed 10 May 2023 at 13:18:07 -0400, gene heskett wrote:
> >
> > > On 5/10/23 11:29, Brian wrote:
> > > > On Wed 10 May 2023 at 10:04:47 -0400, gene heskett wrote:
> > > >
> > > > > On 5/10/23 08:17, Brian wrote:
> > >
> > > > [...]
> >
> > > > Is /etc/cups/client,conf really, really needed?
> > > >
> > > That is the first thing cups docs tell you to do, see "printer sharing"
> >
> > A link would be ever so useful.
>
> send browser to cups.org, click help, in right pane, click "printer
> sharing", scroll down about a screenfull to Automatic using IPP

Thanks to you and debia...@howorth.org.uk. Note that this page is for Apple
CUPS. The one for Deian CUPS is at

https://openprinting.github.io/cups/doc/sharing.html

Havong said that, it should also be noted that the /etc/cups/client.conf is used
when a local spooler is not required and is presented as to be used only as
absolutely necessary. Hardly "the first thing cups docs tell you to do". Why is
it absolutely necessary in your situation?

Additionally, a client.conf overrides the default local server. All the analysis
in this thread has been carried out assuming a functional local server, so I do
not know where that leaves us now if a client.conf has been in the mix all the time..

--
Brian.

[gene heskett]

On 5/11/23 07:07, Brian wrote:
> On Wed 10 May 2023 at 16:02:43 -0400, gene heskett wrote:
>
>> On 5/10/23 14:22, Brian wrote:
>>> On Wed 10 May 2023 at 13:18:07 -0400, gene heskett wrote:
>>>
>>>> On 5/10/23 11:29, Brian wrote:
>>>>> On Wed 10 May 2023 at 10:04:47 -0400, gene heskett wrote:
>>>>>
>>>>>> On 5/10/23 08:17, Brian wrote:
>>>>
>>>>> [...]
>>>
>>>>> Is /etc/cups/client,conf really, really needed?
>>>>>
>>>> That is the first thing cups docs tell you to do, see "printer sharing"
>>>
>>> A link would be ever so useful.
>>
>> send browser to cups.org, click help, in right pane, click "printer
>> sharing", scroll down about a screenfull to Automatic using IPP
>
> Thanks to you and debia...@howorth.org.uk. Note that this page is for Apple

> CUPS. The one for Debian CUPS is at
>
> https://openprinting.github.io/cups/doc/sharing.html
>
Thank you for that link, the other Apple Cups link is first in a google
search, and probably close in DDG too since the search was for cups, not
openprinting as I was not then aware that Mike had moved. Apple should
be ashamed of themselves hanging onto the cups links when they are no
longer writing the authors paychecks.

> Havong said that, it should also be noted that the /etc/cups/client.conf is used
> when a local spooler is not required and is presented as to be used only as
> absolutely necessary. Hardly "the first thing cups docs tell you to do". Why is
> it absolutely necessary in your situation?
>
> Additionally, a client.conf overrides the default local server. All the analysis
> in this thread has been carried out assuming a functional local server, so I do
> not know where that leaves us now if a client.conf has been in the mix all the time..
>

I am wondering now if I shouldn't remove the other Listen directives
from cupsd.conf, isolating their influence when there are no locally
connected printers.

Aha!!!! Got it, geany evince okular etc can now print from bpi54!
Removing the Listen localhost:631 directive from /etc/cups/cupsd.conf
and inserting a

Listen 192.168.xx.yy:631

made the localhost:631/printers on this machine show up in FF on bpi54,
all 5 choices from this machine. All that as root of course, and the
acid test was me as 1st user, calling up geany to edit that file, which
complained it was not writable but to print it on the B&W laser, which
it just did. I did have to leave active the "Listen /run/cups/cups.sock"
line, it did not work w/o that.

I changed the LogLevel back to warn before it fills up a 64BG card, and
it seems its all Just Working.

That warning in the paragraph above s/not be a show stopper when there
is only one machine as the Server on this local network. IMO, it should
be speced as applying to any machine that does NOT have any locally
connected printers.

Your help, and some comments from Greg, have been very helpful. Thank
you both for bearing with me, most appreciated.

Take care & stay well.

[gene heskett]

Yes, it was necessary, see my previous post. Not determined is the need
for a client.conf file with its contents, I rather suspect it might
still be required as its the only "Server" specification in the whole
shebang.

Take care & stay well.

[Brian]

You are, as uaual, treading your own path. Sometimes, it touches on mine
or crosses it. Let's leave it there. The acknowledgement is gracious and
appreciated.

--
Brian.

[Vincent Lefevre]

On 2023-05-11 12:08:01 -0400, gene heskett wrote:
> Aha!!!! Got it, geany evince okular etc can now print from bpi54! Removing
> the Listen localhost:631 directive from /etc/cups/cupsd.conf and inserting a
>
> Listen 192.168.xx.yy:631
>
> made the localhost:631/printers on this machine show up in FF on bpi54, all
> 5 choices from this machine.

Any explanation?

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Greg Wooledge]

On Thu, May 11, 2023 at 11:58:56PM +0200, Vincent Lefevre wrote:
> On 2023-05-11 12:08:01 -0400, gene heskett wrote:
> > Aha!!!! Got it, geany evince okular etc can now print from bpi54! Removing
> > the Listen localhost:631 directive from /etc/cups/cupsd.conf and inserting a
> >
> > Listen 192.168.xx.yy:631
> >
> > made the localhost:631/printers on this machine show up in FF on bpi54, all
> > 5 choices from this machine.
>
> Any explanation?

Seems obvious enough to me. CUPS on bpi54 was only listening to
loopback (localhost), but Gene wanted to print through it remotely.
So he had to make it listen to the network instead.

My questions would be:

1) Can you put *both* Listen lines in, to keep loopback working?

2) Failing that, can you use 0.0.0.0 as the Listen address, to listen on
all interfaces? That's the normal convention.

[Vincent Lefevre]

On 2023-05-11 18:24:39 -0400, Greg Wooledge wrote:
> On Thu, May 11, 2023 at 11:58:56PM +0200, Vincent Lefevre wrote:
> > On 2023-05-11 12:08:01 -0400, gene heskett wrote:
> > > Aha!!!! Got it, geany evince okular etc can now print from bpi54! Removing
> > > the Listen localhost:631 directive from /etc/cups/cupsd.conf and inserting a
> > >
> > > Listen 192.168.xx.yy:631
> > >
> > > made the localhost:631/printers on this machine show up in FF on bpi54, all
> > > 5 choices from this machine.
> >
> > Any explanation?
>
> Seems obvious enough to me. CUPS on bpi54 was only listening to
> loopback (localhost), but Gene wanted to print through it remotely.
> So he had to make it listen to the network instead.

My question was more on why does this affect localhost:631/printers?

> My questions would be:
>
> 1) Can you put *both* Listen lines in, to keep loopback working?

The cupsd.conf(5) man page says: "Multiple Listen directives can be
provided to listen on multiple addresses."

> 2) Failing that, can you use 0.0.0.0 as the Listen address, to listen on
> all interfaces? That's the normal convention.

According to the cupsd.conf(5) man page, you can use "Listen *:631".

[gene heskett]

On 5/11/23 17:59, Vincent Lefevre wrote:
> On 2023-05-11 12:08:01 -0400, gene heskett wrote:
>> Aha!!!! Got it, geany evince okular etc can now print from bpi54! Removing
>> the Listen localhost:631 directive from /etc/cups/cupsd.conf and inserting a
>>
>> Listen 192.168.xx.yy:631
>>
>> made the localhost:631/printers on this machine show up in FF on bpi54, all
>> 5 choices from this machine.
>
> Any explanation?
>

My best guess is the Server directive in client.conf was rejected
because there was already a couple "Listen" directives pointing at
itself. Remove the main one and the client.conf was able to take over.
Or the substition of a "Listen ipv4-address-of-server:631" is also a
possibility.

Whatever, the point now is that it Just Works.

A lot of hacking on C-89 has taken place since the last C book was
published by K&R, so I am not the C guru I was in the 1990's.

I'm now 88 yo and some of me has gone to the dogs too. Take that as an
admission that my diagnosis might be wrong, but I've been chasing
electrons to make then do useful work since about 1948 when I quit
school and went to work fixing them new fangled things called tv's.

Take care & stay well, Vincent.

[gene heskett]

On 5/11/23 18:25, Greg Wooledge wrote:
> On Thu, May 11, 2023 at 11:58:56PM +0200, Vincent Lefevre wrote:
>> On 2023-05-11 12:08:01 -0400, gene heskett wrote:
>>> Aha!!!! Got it, geany evince okular etc can now print from bpi54! Removing
>>> the Listen localhost:631 directive from /etc/cups/cupsd.conf and inserting a
>>>
>>> Listen 192.168.xx.yy:631
>>>
>>> made the localhost:631/printers on this machine show up in FF on bpi54, all
>>> 5 choices from this machine.
>>
>> Any explanation?
>
> Seems obvious enough to me. CUPS on bpi54 was only listening to
> loopback (localhost), but Gene wanted to print through it remotely.
> So he had to make it listen to the network instead.

Close, I wanted to be able to print from the bpi from any app on the bpi
that had a print this option. Now I can.

>
> My questions would be:
>
> 1) Can you put *both* Listen lines in, to keep loopback working?

No, that kills the cups ability to query the network even with the
Server named in client.conf. It even logs it as a failure, on the bpi5

but doesn't say why.

> 2) Failing that, can you use 0.0.0.0 as the Listen address, to listen on
> all interfaces? That's the normal convention.

Untried, so can't say. And I've not read far enough to see that as an
example.

Thanks Greg.

[gene heskett]

On 5/11/23 19:41, Vincent Lefevre wrote:
> On 2023-05-11 18:24:39 -0400, Greg Wooledge wrote:
>> On Thu, May 11, 2023 at 11:58:56PM +0200, Vincent Lefevre wrote:
>>> On 2023-05-11 12:08:01 -0400, gene heskett wrote:
>>>> Aha!!!! Got it, geany evince okular etc can now print from bpi54! Removing
>>>> the Listen localhost:631 directive from /etc/cups/cupsd.conf and inserting a
>>>>
>>>> Listen 192.168.xx.yy:631
>>>>
>>>> made the localhost:631/printers on this machine show up in FF on bpi54, all
>>>> 5 choices from this machine.
>>>
>>> Any explanation?
>>
>> Seems obvious enough to me. CUPS on bpi54 was only listening to
>> loopback (localhost), but Gene wanted to print through it remotely.
>> So he had to make it listen to the network instead.
>
> My question was more on why does this affect localhost:631/printers?
>
>> My questions would be:
>>
>> 1) Can you put *both* Listen lines in, to keep loopback working?
>
> The cupsd.conf(5) man page says: "Multiple Listen directives can be
> provided to listen on multiple addresses."
>

My results seem to indicate otherwise.

>> 2) Failing that, can you use 0.0.0.0 as the Listen address, to listen on
>> all interfaces? That's the normal convention.
>
> According to the cupsd.conf(5) man page, you can use "Listen *:631".

The possibility exists that the star goes thru a different path, which
works. untested here. But folks, that isn't a SWAG, its a plain old WAG.

[Vincent Lefevre]

On 2023-05-11 21:34:11 -0400, gene heskett wrote:
> On 5/11/23 19:41, Vincent Lefevre wrote:
> > On 2023-05-11 18:24:39 -0400, Greg Wooledge wrote:
> > > My questions would be:
> > >
> > > 1) Can you put *both* Listen lines in, to keep loopback working?
> >
> > The cupsd.conf(5) man page says: "Multiple Listen directives can be
> > provided to listen on multiple addresses."
> >
> My results seem to indicate otherwise.

I don't think that you even showed anything. The only test you
should do about that is to try to connect to the port, e.g. with
telnet (or nmap can probably tell you). If the connection isn't
immediately refused, then the Listen directive is OK.

For instance:

zira:~> telnet localhost 631
Trying ::1...
flushoutput character is 'off'.
Connected to localhost.
Escape character is '^]'.

Fine. And you can try the same thing from a different machine on
the network, replacing "localhost" by the IP address of the server,
e.g. from another machine on my network:

$ telnet 192.168.1.3 631
Trying 192.168.1.3...
telnet: Unable to connect to remote host: Connection refused

because my CUPS server just has

Listen localhost:631
Listen /var/run/cups/cups.sock

If the connection is accepted with telnet by using multiple Listen
directives, then the Listen configuration is correct. If you can
see any other issue related to the printers, then the problem is
due to something else.

[gene heskett]

I'm confused. There is not anything wrong with this machine as a Server.
ALL of this muttering and bitching has been because bookworm clients did
NOT work. buster clients work great.

How many times do I have to say it is/was a CLIENT problem that only
exists for BOOKWORM clients. The elephant in the room that most have
ignored.

What I have done, on the BOOKWORM CLIENT works, but we still don't have
a clue why that is so.

That said i've dl'd the src from cups, which is broken by not being in a
state that will even autogen. So I dl'd the obviously much later
src.zip from Mikes new openprinting site. The zip is about 250% the size
of the apple tar.gz. Its complete and only needs one argument to
configure, with-tls=no. Then it builds and passes a make test, but I've
not installed it on this machine.

The debian code appears to be the Apple src.
What I intend to do is move the openprinting version 2.4.5 to one of the
bpi's, see if it will build there, and install it on the bpi to see if
that works. But I'm just one, and there is only so much I can do in a day.

[gene heskett]

I'm not able to test that on the bpi's, telnet is not installed.

> because my CUPS server just has
>
> Listen localhost:631
> Listen /var/run/cups/cups.sock
>
> If the connection is accepted with telnet by using multiple Listen
> directives, then the Listen configuration is correct. If you can
> see any other issue related to the printers, then the problem is
> due to something else.
>

[Greg Wooledge]

On Fri, May 12, 2023 at 06:26:00AM -0400, gene heskett wrote:
> On 5/12/23 05:18, Vincent Lefevre wrote:
> > Fine. And you can try the same thing from a different machine on
> > the network, replacing "localhost" by the IP address of the server,
> > e.g. from another machine on my network:
> >
> > $ telnet 192.168.1.3 631
> > Trying 192.168.1.3...
> > telnet: Unable to connect to remote host: Connection refused
> >
> I'm not able to test that on the bpi's, telnet is not installed.

Then install it, or use an EQUIVALENT command.

[Vincent Lefevre]

On 2023-05-12 06:23:56 -0400, gene heskett wrote:
> I'm confused. There is not anything wrong with this machine as a Server.
> ALL of this muttering and bitching has been because bookworm clients did NOT
> work. buster clients work great.
>
> How many times do I have to say it is/was a CLIENT problem that only exists
> for BOOKWORM clients. The elephant in the room that most have ignored.

But you said that the problem was "solved" by modifying a setting
corresponding to the Listen directives (in /etc/cups/cupsd.conf).
These directives concern the *server* only.

I suspect that your problem was solved for another reason (e.g.
something else occurred on the network in the mean time, or some
config was reloaded at the right time, possibly as a consequence
of your testing). Or perhaps it is not solved at all and could
reappear in the future (that's why it would be interesting to
know the real cause of the problem).

[Vincent Lefevre]

On 2023-05-12 06:26:00 -0400, gene heskett wrote:
> I'm not able to test that on the bpi's, telnet is not installed.

You can try with nmap:

$ nmap -p 631 localhost
$ nmap -p 631 <server_IP>

PORT STATE SERVICE
631/tcp open ipp

means that you can connect.

PORT STATE SERVICE
631/tcp closed ipp

means that you can't.

[gene heskett]

On 5/12/23 07:41, Vincent Lefevre wrote:
> On 2023-05-12 06:23:56 -0400, gene heskett wrote:
>> I'm confused. There is not anything wrong with this machine as a Server.
>> ALL of this muttering and bitching has been because bookworm clients did NOT
>> work. buster clients work great.
>>
>> How many times do I have to say it is/was a CLIENT problem that only exists
>> for BOOKWORM clients. The elephant in the room that most have ignored.
>
> But you said that the problem was "solved" by modifying a setting
> corresponding to the Listen directives (in /etc/cups/cupsd.conf).
> These directives concern the *server* only.
>

Oh, then how does one tell the CLIENT to even use the SERVER? That
statement, added to a created CLIENT.CONF, is not sufficient, Been tried
many times. It does log a lack of auth, also reported here. Is that the
real problem? The lack of any tracing info in the log, even at debug2
level reporting is a huge hindrance to intelligent trouble shooting.

> I suspect that your problem was solved for another reason (e.g.
> something else occurred on the network in the mean time, or some
> config was reloaded at the right time, possibly as a consequence
> of your testing). Or perhaps it is not solved at all and could
> reappear in the future (that's why it would be interesting to
> know the real cause of the problem).
>

copied new cup-master.zip to the bpi51
unpacked it to cups-master in ~/gene/src
./configure --with-tls=no, no show-stoppers.
make no-show stoppers
make test, failed for 2 functions
the report said at one place it got 34 errors but only expected 33
I didn't install

Back to the apple version installed, what fixed the bpi54 ddoes not fix
the bpi51, so Vincent was right to be concerned

It is 100% a "cannot assign requested address error" on the bpi51 as
logged in/var/log/cups/error_log:

E [12/May/2023:10:32:20 -0500] Unable to open listen socket for address
192.168.71.3:631 - Cannot assign requested address.
E [12/May/2023:10:34:45 -0500] Unable to open listen socket for address

[v1.::1]:631 - Cannot assign requested address.

Where its getting the ipv6 addy is a mystery

ip a:
gene@bpi51:~/src/cups-master$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether ae:c8:46:2e:6b:6b brd ff:ff:ff:ff:ff:ff permaddr
da:0e:c7:cf:52:52
inet 192.168.nn.y/24 brd 192.168.nn.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever

ip r:
gene@bpi51:~/src/cups-master$ ip r
default via 192.168.nn.y dev eth0 proto static metric 100
169.254.0.0/16 dev eth0 scope link metric 1000
192.168.nn.y/24 dev eth0 proto kernel scope link src 192.168.nn.y metric
100

So, how can we proceed?

[gene heskett]

On 5/12/23 07:49, Vincent Lefevre wrote:
> nmap -p 631 localhost

had to install 5 pkgs to get it, but:
gene@bpi51:~/src/cups-master$ nmap -p 631 localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2023-05-12 11:10 -05
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00030s latency).

PORT STATE SERVICE
631/tcp open ipp

Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds
gene@bpi51:~/src/cups-master$ nmap -p 631 192.168.nn.y
Starting Nmap 7.80 ( https://nmap.org ) at 2023-05-12 11:11 -05
Nmap scan report for coyote.coyote.den (192.168.nn.y)
Host is up (0.00073s latency).

PORT STATE SERVICE
631/tcp open ipp

Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
ditto for machines name, so the host file is working.

Next?

Cheers, Geneh Heskett.

[Brian]

On Fri 12 May 2023 at 06:23:56 -0400, gene heskett wrote:

[...]

> I'm confused. There is not anything wrong with this machine as a Server.
> ALL of this muttering and bitching has been because bookworm clients did NOT
> work. buster clients work great.

"work(s)" is such vague term. I guess working and non-working are references
to

> All of my bullseye machines are locked out, printer screen at
> localhost:631 is empty, and no printers can be found and added

> How many times do I have to say it is/was a CLIENT problem that only exists
> for BOOKWORM clients. The elephant in the room that most have ignored.

THe issue has been fully dealt with. In short:

No local printers leads to an empty localhost:631 and 'lpstat -t'.

THere isn't any issue whatsoever. You seem very reluctant to incorporate this
basic fact into your thinking. THe room is empty.

May we have 'lpstat -t' from a buster machine that is not bpi54?

--
Brian.

[gene heskett]

This is buster, running a milling machine in the garage

gene@GO704:~$ lpstat -t
scheduler is running
no system default destination
device for Brother_HL_L2320D_series_coyote:
implicitclass://Brother_HL_L2320D_series_coyote/
device for Brother_MFC_J6920DW: ipp://BRN30055C8A2DC8.local:631/ipp/print
device for Brother_MFC_J6920DW_coyote:
implicitclass://Brother_MFC_J6920DW_coyote/
device for HLL2320D_coyote: implicitclass://HLL2320D_coyote/
device for MFCJ6920DW_tray_2_coyote: ///dev/null
Brother_HL_L2320D_series_coyote accepting requests since Fri 12 May 2023
12:00:02 AM EDT
Brother_MFC_J6920DW accepting requests since Fri 12 May 2023 12:00:02 AM EDT
Brother_MFC_J6920DW_coyote accepting requests since Fri 12 May 2023
12:00:02 AM EDT
HLL2320D_coyote accepting requests since Fri 12 May 2023 12:00:02 AM EDT
MFCJ6920DW_tray_2_coyote not accepting requests since Wed 03 May 2023
12:00:02 AM EDT -
reason unknown
printer Brother_HL_L2320D_series_coyote is idle. enabled since Fri 12
May 2023 12:00:02 AM EDT
printer Brother_MFC_J6920DW is idle. enabled since Fri 12 May 2023
12:00:02 AM EDT
printer Brother_MFC_J6920DW_coyote is idle. enabled since Fri 12 May
2023 12:00:02 AM EDT
printer HLL2320D_coyote is idle. enabled since Fri 12 May 2023 12:00:02
AM EDT
printer MFCJ6920DW_tray_2_coyote disabled since Wed 03 May 2023 12:00:02
AM EDT -
reason unknown

this is another gantry style machine:
gene@sixty40:~$ lpstat -t
scheduler is running
no system default destination
device for Brother_HL_L2320D_series_coyote: ///dev/null
device for Brother_MFC_J6920DW: ipp://BRN30055C8A2DC8.local:631/ipp/print
device for Brother_MFC_J6920DW_coyote: ///dev/null
Brother_HL_L2320D_series_coyote not accepting requests since Sun 23 Apr
2023 12:00:03 AM EDT -
reason unknown
Brother_MFC_J6920DW accepting requests since Fri 12 May 2023 12:00:14 AM EDT
Brother_MFC_J6920DW_coyote not accepting requests since Thu 20 Apr 2023
12:00:03 AM EDT -
reason unknown
printer Brother_HL_L2320D_series_coyote disabled since Sun 23 Apr 2023
12:00:03 AM EDT -
reason unknown
printer Brother_MFC_J6920DW is idle. enabled since Fri 12 May 2023
12:00:14 AM EDT
printer Brother_MFC_J6920DW_coyote disabled since Thu 20 Apr 2023
12:00:03 AM EDT -
reason unknown

and this is an rpi4b running a 1500 lb lathe:
pi@rpi4:~ $ lpstat -t
scheduler is running
no system default destination
device for Brother_HL-L2320D_series:
usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
device for Brother_MFC-J6920DW_photo:
usb://Brother/MFC-J6920DW?serial=BROG5F229909
device for MFCJ6920DW: usb://Brother/MFC-J6920DW?serial=BROG5F229909
Brother_HL-L2320D_series accepting requests since Tue 09 May 2023
05:23:01 PM EDT
Brother_MFC-J6920DW_photo accepting requests since Thu 30 Mar 2023
09:16:43 AM EDT
MFCJ6920DW accepting requests since Sun 26 Mar 2023 03:30:13 PM EDT
printer Brother_HL-L2320D_series is idle. enabled since Tue 09 May 2023
05:23:01 PM EDT
printer Brother_MFC-J6920DW_photo is idle. enabled since Thu 30 Mar
2023 09:16:43 AM EDT
printer MFCJ6920DW is idle. enabled since Sun 26 Mar 2023 03:30:13 PM EDT

there is a 2nd smaller lathe in a shed in the upper rear corner of the
place that has been kept uptodate but is in the middle of a hardware
update for linuxcnc, and its a suprise:

gene@TLM:~$ lpstat -t
scheduler is not running
no system default destination
lpstat: Bad file descriptor
lpstat: Bad file descriptor
lpstat: Bad file descriptor
lpstat: Bad file descriptor
lpstat: Bad file descriptor

but cups is not installed, its missing from .etc/init.d, rebooting
didn't change.
machine updates and cups and friends installed:
gene@TLM:~$ lpstat -t
scheduler is running
no system default destination
device for Brother_HL_L2320D_series_coyote:
implicitclass://Brother_HL_L2320D_series_coyote/
device for Brother_MFC_J6920DW: ipp://BRN30055C8A2DC8.local:631/ipp/print
device for Brother_MFC_J6920DW_coyote:
implicitclass://Brother_MFC_J6920DW_coyote/
device for HLL2320D_coyote: implicitclass://HLL2320D_coyote/
device for MFCJ6920DW_tray_2_coyote:
implicitclass://MFCJ6920DW_tray_2_coyote/
Brother_HL_L2320D_series_coyote accepting requests since Fri 12 May 2023
03:21:26 PM EDT
Brother_MFC_J6920DW accepting requests since Fri 12 May 2023 03:20:24 PM EDT
Brother_MFC_J6920DW_coyote accepting requests since Fri 12 May 2023
03:21:26 PM EDT
HLL2320D_coyote accepting requests since Fri 12 May 2023 03:21:26 PM EDT
MFCJ6920DW_tray_2_coyote accepting requests since Fri 12 May 2023
03:21:26 PM EDT
printer Brother_HL_L2320D_series_coyote is idle. enabled since Fri 12
May 2023 03:21:26 PM EDT
printer Brother_MFC_J6920DW is idle. enabled since Fri 12 May 2023
03:20:24 PM EDT
printer Brother_MFC_J6920DW_coyote is idle. enabled since Fri 12 May
2023 03:21:26 PM EDT
printer HLL2320D_coyote is idle. enabled since Fri 12 May 2023 03:21:26
PM EDT
printer MFCJ6920DW_tray_2_coyote is idle. enabled since Fri 12 May 2023
03:21:26 PM EDT

all those running uptodate buster. opening and re-closing both paper
trays on the 6920 fixed that error

[Vincent Lefevre]

On 2023-05-12 12:08:33 -0400, gene heskett wrote:
> On 5/12/23 07:41, Vincent Lefevre wrote:
> > On 2023-05-12 06:23:56 -0400, gene heskett wrote:
> > > I'm confused. There is not anything wrong with this machine as a Server.
> > > ALL of this muttering and bitching has been because bookworm clients did NOT
> > > work. buster clients work great.
> > >
> > > How many times do I have to say it is/was a CLIENT problem that only exists
> > > for BOOKWORM clients. The elephant in the room that most have ignored.
> >
> > But you said that the problem was "solved" by modifying a setting
> > corresponding to the Listen directives (in /etc/cups/cupsd.conf).
> > These directives concern the *server* only.
> >
> Oh, then how does one tell the CLIENT to even use the SERVER?

I'm not sure what you mean by "use". In the past, I had the following
lines in the /etc/cups/client.conf file of the machine at my lab:

ServerName liqqs.lip.ens-lyon.fr:443
Encryption Required
ValidateCerts Yes

The first line is to tell which server to use, and the other lines
for security. This way of doing means that everything is configured
on the server.

This has been deprecated at my lab, and now, the printers need to be
configured directly on the client side. In case you want something
like that, AFAIK, there are 2 solutions:

Manual: something like
lpadmin -p <name> -v <URI> [ -E ] -m everywhere -L <location>

Automatic with the cups-browsed package:

Description: OpenPrinting CUPS Filters - cups-browsed
This package provides cups-browsed, a daemon which browses the Bonjour
broadcasts of shared remote CUPS printers and makes the printers
available locally, replacing the CUPS broadcasting/browsing which was
dropped in CUPS 1.6.x. This way the old behavior of having the remote
printers available automatically is now re-implemented with Bonjour.

(However, it appears that because of that, on my laptop, I now have
dozens of ghost printers, and this is annoying.)

> It is 100% a "cannot assign requested address error" on the bpi51 as logged
> in/var/log/cups/error_log:
>
> E [12/May/2023:10:32:20 -0500] Unable to open listen socket for address
> 192.168.71.3:631 - Cannot assign requested address.
> E [12/May/2023:10:34:45 -0500] Unable to open listen socket for address
> [v1.::1]:631 - Cannot assign requested address.

I suppose that this is because you already have a server that is
already running and listening on these ports. Or you started the
server too soon after the old one terminated.

> Where its getting the ipv6 addy is a mystery

::1 is the IPv6 loopback. Perhaps listening on it is the default
(this makes sense), and perhaps even if it isn't setup (as this
is unusual).

[Brian]

On Fri 12 May 2023 at 15:27:21 -0400, gene heskett wrote:

> On 5/12/23 14:45, Brian wrote:
> > On Fri 12 May 2023 at 06:23:56 -0400, gene heskett wrote:
> >
> > [...]
> >
> > > I'm confused. There is not anything wrong with this machine as a Server.
> > > ALL of this muttering and bitching has been because bookworm clients did NOT
> > > work. buster clients work great.
> >
> > "work(s)" is such vague term. I guess working and non-working are references
> > to
> >
> > > All of my bullseye machines are locked out, printer screen at
> > > localhost:631 is empty, and no printers can be found and added
> >
> > > How many times do I have to say it is/was a CLIENT problem that only exists
> > > for BOOKWORM clients. The elephant in the room that most have ignored.
> >
> > THe issue has been fully dealt with. In short:
> >
> > No local printers leads to an empty localhost:631 and 'lpstat -t'.
> >
> > THere isn't any issue whatsoever. You seem very reluctant to incorporate this
> > basic fact into your thinking. THe room is empty.
> >
> > May we have 'lpstat -t' from a buster machine that is not bpi54?
>
> This is buster, running a milling machine in the garage

[Informative info from a number of machines snupped.]

All the displayed queues are local and have either been set up manually (ipp://...)
or autmatically by cups-browsed (implicitclass://...). A manual setup on a
bullseye machine would involve the raw or everywhere model. A client.conf is an
is an alternative.

--
Brian.

[gene heskett]

But it doesn't seem to work in armbian bullseye, who uses debian repo's
for everything not involved with booting. Most armbian stuff is u-boot.

I now have different results between bpi54, which works, and bpi51,
which does not. The two are I believe configured identically in /etc/cups.