Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

On 5/11/23 07:09, Brian wrote:

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.

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.

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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[debian-user]

gene heskett  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 :)

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.



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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.
  

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.

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.

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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.


Take care & stay well.

 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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[tomas]

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


signature.asc
Description: PGP signature

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

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

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.


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.

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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

.


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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.
--
"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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

On 5/8/23 16:57, gene heskett wrote:

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.


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?





   > 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.


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.


Took them till close to noon to find it.

Thanks Brian.

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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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 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.


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.
--
"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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.


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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

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

On Sun 07 May 2023 at 11:26:05 -0400, gene heskett wrote:


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.


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:/
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

Re: repeat of previous question that has gone unansweredseveraltimes.

[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
edua...@kalinowski.com.br

Re: repeat of previous question that has gone unansweredseveraltimes.

[Brian]

On Sun 07 May 2023 at 11:26:05 -0400, gene heskett wrote:

> 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.

Please give 'lpstat -t' for bpi51 (bullseye) and a buster machine.
 
> 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?

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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[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 wit

Re: repeat of previous question that has gone unansweredseveraltimes.

[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
edua...@kalinowski.com.br

Re: repeat of previous question that has gone unansweredseveraltimes.

[Charlie Gibbs]

On Sat May  6 21:11:09 2023 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.
>
> 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.



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.
\ /|  It can be beautiful -
 X   I'm really at ac.dekanfrus |  but it won't.
/ \  if you read it the right way.  |-- Lily Tomlin

Re: repeat of previous question that has gone unansweredseveraltimes.

[Byung-Hee HWANG]

Alex King  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

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

Re: repeat of previous question that has gone unansweredseveraltimes.

[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!



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

Re: repeat of previous question that has gone unansweredseveraltimes.

[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

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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

On 5/5/23 18:51, Brian wrote:

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.

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.

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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.



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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

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.


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.

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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

On 5/1/23 17:22, Brian wrote:

On Mon 01 May 2023 at 20:59:50 +0100, debian-u...@howorth.org.uk wrote:


gene heskett  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.


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.



And it did not exist until the lpadmin created it.

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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

On 5/1/23 14:31, Brian wrote:

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.

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.

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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

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

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

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.





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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[debian-user]

gene heskett  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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

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

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.


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.


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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

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

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.


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 lp4096 May  1 00:00 ppd
-rw--- 1 root lp1882 May  1 00:00 printers.conf
-rw--- 1 root lp 111 May  1 00:00 printers.conf.O
drwx-- 2 root lp4096 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 lp4096 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 lp4096 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)>


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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

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



   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.






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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[Brian]

On Mon 01 May 2023 at 10:56:00 -0400, gene heskett wrote:

> On 5/1/23 10:08, David Wright wrote:
> > 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.
> > 
> > .
> 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"

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

-- 
Brian.

Re: repeat of previous question that has gone unansweredseveraltimes.

[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.

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

On 5/1/23 11:03, gene heskett wrote:

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

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


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.



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


Cheers, Gene Heskett.


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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

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

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


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.


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 

Re: repeat of previous question that has gone unansweredseveraltimes.

[gene heskett]

On 5/1/23 10:08, David Wright wrote:

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.

.

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"

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