Well, with cups-common-2.3.3op2-1.1.mga8, at least 'lp' and 'lpq' work.
Just doing the update to cups-common-2.3.3op2-1.2.mga8. Will re-boot to try it.

CC: (none) => lewyssmith

Re-booted with cups-common-2.3.3op2-1.2.mga8.
$ ls -l /usr/bin |grep lpq
lrwxrwxrwx   1 root root           27 Hyd  16  2022 lpq -> /etc/alternatives/print-lpq*
-rwxr-xr-x   1 root root        23664 Meh   5 14:20 lpq.cups*
lrwxrwxrwx   1 root root           17 Tach 15  2020 lpq-foomatic -> foomatic-printjob*

All 3 commands cited in the bug title worked:

 $ lpq
EPSON-Stylus-D92 is ready
no entries

Printer on:
 $ lp -
RUBBISH
request id is EPSON-Stylus-D92-15 (0 file(s))
 The text was printed immediately.

Printer off:
 $ lp -
QUEUED
request id is EPSON-Stylus-D92-16 (0 file(s))

 $ lpq
EPSON-Stylus-D92 is ready and printing
Rank    Owner   Job     File(s)                         Total Size
active  lewis   16      (stdin)                         1024 bytes

 $ lprm 16

 $ lpq
EPSON-Stylus-D92 is ready
no entries

Or have I misunderstood the complaint?

Ever confirmed: 1 => 0
Status: NEW => UNCONFIRMED

On my m8 x86_64 install that has a printer attached ...
[dave@x3 ~]$ lpq
Canon-PIXMA-MP150 is ready
no entries
[dave@x3 ~]$ ls -l /usr/bin/lpq
lrwxrwxrwx 1 root root 27 Mar  4  2021 /usr/bin/lpq -> /etc/alternatives/print-lpq*
[dave@x3 ~]$ ls -l /etc/alternatives/print-lpq
lrwxrwxrwx 1 root root 17 Mar  4  2021 /etc/alternatives/print-lpq -> /usr/bin/lpq.cups*
[dave@x3 ~]$ ls -l /usr/bin/lpq.cups
-rwxr-xr-x 1 root root 23664 Jun  5 08:20 /usr/bin/lpq.cups*

CC: (none) => davidwhodgins

Well, Peter?

(In reply to Lewis Smith from comment #4)
> Well, Peter?

yes, but I'd to replace in /usr/bin all sl leading to /etc/alternatives/lpxx by /etc/alternatives/print-lpxx (idem for lpc in /usr/sbin) and to remove the old sl lpxx in /etc/alternatives and to refresh /etc/cups/lpoptions
now everything seems to normally work 
best regards

Thanks for that. I will look again tomorrow.

I did, at length - but for Mageia 9 rather than 8!
The devious circuit /usr/bin/lp* -> /etc/alternatives/lp* -> /usr/bin/lp*.cups (rather than direct linking in /usr/bin/) is intact everywhere here.

I will look on M8 when I remember. Your problem was some '-cups' instead of '.cups', as you noted in comment 0. For the moment you have sorted yourself out.

Mageia 8.

 $ ls -l /usr/bin/lp*
lrwxrwxrwx 1 root root     26 Hyd  16  2022 /usr/bin/lp -> /etc/alternatives/print-lp*
-rwxr-xr-x 1 root root  27624 Meh   5 14:20 /usr/bin/lp.cups*
-rwxr-xr-x 1 root root  23632 Meh   5 14:20 /usr/bin/lpoptions*
lrwxrwxrwx 1 root root     27 Hyd  16  2022 /usr/bin/lpq -> /etc/alternatives/print-lpq*
-rwxr-xr-x 1 root root  23664 Meh   5 14:20 /usr/bin/lpq.cups*
lrwxrwxrwx 1 root root     17 Tach 15  2020 /usr/bin/lpq-foomatic -> foomatic-printjob*
lrwxrwxrwx 1 root root     23 Hyd  16  2022 /usr/bin/lpr -> /etc/alternatives/print*
-rwxr-xr-x 1 root root  15328 Meh   5 14:20 /usr/bin/lpr.cups*
lrwxrwxrwx 1 root root     17 Tach 15  2020 /usr/bin/lpr-foomatic -> foomatic-printjob*
lrwxrwxrwx 1 root root     28 Hyd  16  2022 /usr/bin/lprm -> /etc/alternatives/print-lprm*
-rwxr-xr-x 1 root root  15320 Meh   5 14:20 /usr/bin/lprm.cups*
lrwxrwxrwx 1 root root     17 Tach 15  2020 /usr/bin/lprm-foomatic -> foomatic-printjob*
-rwxr-xr-x 1 root root   5474 Ebr   6 10:45 /usr/bin/lprsetup.sh*
-rwxr-xr-x 1 root root 591112 Chw  13  2020 /usr/bin/lp_solve*
lrwxrwxrwx 1 root root     30 Hyd  16  2022 /usr/bin/lpstat -> /etc/alternatives/print-lpstat*
-rwxr-xr-x 1 root root  40336 Meh   5 14:20 /usr/bin/lpstat.cups*
 +
lrwxrwxrwx 1 root root    30 Hyd  16  2022 /usr/bin/cancel -> /etc/alternatives/print-cancel*
-rwxr-xr-x 1 root root 15336 Meh   5 14:20 /usr/bin/cancel.cups*

Summarising the redirects:

 $ ls -l /usr/bin/lp* | grep alternatives
lrwxrwxrwx 1 root root     26 Hyd  16  2022 /usr/bin/lp -> /etc/alternatives/print-lp*
lrwxrwxrwx 1 root root     27 Hyd  16  2022 /usr/bin/lpq -> /etc/alternatives/print-lpq*
lrwxrwxrwx 1 root root     23 Hyd  16  2022 /usr/bin/lpr -> /etc/alternatives/print*
lrwxrwxrwx 1 root root     28 Hyd  16  2022 /usr/bin/lprm -> /etc/alternatives/print-lprm*
lrwxrwxrwx 1 root root     30 Hyd  16  2022 /usr/bin/lpstat -> /etc/alternatives/print-lpstat*
 +
lrwxrwxrwx 1 root root    30 Hyd  16  2022 /usr/bin/cancel -> /etc/alternatives/print-cancel*

 $ ls -l /etc/alternatives | grep cups | grep -v /man/  [without the smb line]
lrwxrwxrwx 1 root root 17 Hyd  16  2022 print -> /usr/bin/lpr.cups*
lrwxrwxrwx 1 root root 20 Hyd  16  2022 print-cancel -> /usr/bin/cancel.cups*
lrwxrwxrwx 1 root root 16 Hyd  16  2022 print-lp -> /usr/bin/lp.cups*
lrwxrwxrwx 1 root root 18 Hyd  16  2022 print-lpc -> /usr/sbin/lpc.cups*
lrwxrwxrwx 1 root root 17 Hyd  16  2022 print-lpq -> /usr/bin/lpq.cups*
lrwxrwxrwx 1 root root 18 Hyd  16  2022 print-lprm -> /usr/bin/lprm.cups*
lrwxrwxrwx 1 root root 20 Hyd  16  2022 print-lpstat -> /usr/bin/lpstat.cups*

All the command redirects to /etc/alternatives/ invent a link name 'print-command' which then returns to /usr/bin/ as 'command.cups'.
One can see the inconsistencies in your comment 0.

In your /usr/bin, taking 'lpq' as the example (you say also for 'lp' & 'lprm'),
 lpq -> /etc/alternatives/lpq   [rather than print-lpq]
is wrong. As is:
 /etc/alternatives/lpq is a symbolic link to /usr/bin/lpq-cups  [rather than lpq.cups].

Comment 3 shows the same correct situation explicitly.
Since these errors produce visible command failures, many people would be complaining if they were in the field. We must remain in the dark about how your system got deformed.

Can we close this now?

I am also having issues with lp in Mga9 and Mga8.

I have always used lp to print postscript files - the last time in Mga8 I used it was maybe six months ago or more so there have been updates since then.

On installing my printer in Mga8 or Mga9 I can print a test page without problem.

On attempting to print a .ps I see:

-rw-r--r-- 1 baz baz 376113 Jul 20 12:45 antsys_swr_RX_27.bottom.ps

This in Mga9:
[baz@localhost cups]$ lp antsys_swr_RX_27.bottom.ps
request id is Samsung-SCX-4x21-Series-2 (1 file(s))
[baz@localhost cups]$

Then the printer just sits there for ever doing nothing.

This is from Mga8:
[baz@jackodesktop ~]$ lpq
Samsung-SCX-4x21-Series-2 is ready and printing
Rank    Owner   Job     File(s)                         Total Size
active  baz     95      antsys_swr_RX_27.bottom.ps      376832 bytes

The print queue has the file apparently printing, so attempting to print anything else just fails as it's added to the queue.

CC: (none) => zen25000

The same printer and .ps files print perfectly in a clean net install of Mageia 7.1 so this is a regression in recent cups on Mga8 and Mga9.

Does this require a new bug report?

Priority: Normal => High
Severity: normal => major

(In reply to Barry Jackson from comment #10)
> The same printer and .ps files print perfectly in a clean net install of
> Mageia 7.1 so this is a regression in recent cups on Mga8 and Mga9.
> 
> Does this require a new bug report?

of course, a regression in Mageia is not conceivable

but a simple way to overcome the problem, if you don't want to turn off your printer at each shutdown of your computer, and to turn on again after computer's boot is to unplug the usb link of the printer and immediately after to plug it in again

Are the group memberships the same in both the working and non-working
installs?

(In reply to peter lawford from comment #11)
> (In reply to Barry Jackson from comment #10)
> > The same printer and .ps files print perfectly in a clean net install of
> > Mageia 7.1 so this is a regression in recent cups on Mga8 and Mga9.
> > 
> > Does this require a new bug report?
> 
> of course, a regression in Mageia is not conceivable

I read that as sarcasm.

I was referring to whether to continue in this report or whether to start a new one. I am guessing it's a similar but not identical bug.

(In reply to peter lawford from comment #12)
> but a simple way to overcome the problem, if you don't want to turn off your
> printer at each shutdown of your computer, and to turn on again after
> computer's boot is to unplug the usb link of the printer and immediately
> after to plug it in again

If the printer has just printed a test page why would turning it off and on again help?

Maybe I should have opened a new bug report as you must be on a different topic.

(In reply to Dave Hodgins from comment #13)
> Are the group memberships the same in both the working and non-working
> installs?

I did see a report elsewhere that mentioned an lp group which I don't remember seeing before.

In the working Mga7.1 system my user does not belong to any groups other than the default personal group.

In the Mageia 8 system my user is in various groups but not lp.
Likewise in one of the Mageia 9 systems that I have tested.

Adding myself to the lp group made no difference.
I can print a web page without a problem and immediately try to print a postscript file and see the following:

[baz@jackodesktop ~]$ lp /home/baz/Geda/ANTROT_RX/antsys_swr_RX_27.bottom.ps
request id is Samsung-SCX-4x21-Series-11 (1 file(s))
[baz@jackodesktop ~]$ lpq
Samsung-SCX-4x21-Series is ready and printing
Rank    Owner   Job     File(s)                         Total Size
active  baz     11      antsys_swr_RX_27.bottom.ps      376832 bytes
[baz@jackodesktop ~]$

Nothing is printed.

After adding the your user id to the group, logout/in is required for the
change to take effect.

(In reply to Dave Hodgins from comment #16)
> After adding the your user id to the group, logout/in is required for the
> change to take effect.

Yes - that was done :)

(In reply to Barry Jackson from comment #14)
> (In reply to peter lawford from comment #11)
> > (In reply to Barry Jackson from comment #10)
> > > The same printer and .ps files print perfectly in a clean net install of
> > > Mageia 7.1 so this is a regression in recent cups on Mga8 and Mga9.
> > > 
> > > Does this require a new bug report?
> > 
> > of course, a regression in Mageia is not conceivable
> 
> I read that as sarcasm.

it's not really a sarcasm, I sincerly think and hope that Mageia would be one of the best distro in the world linux
> 
> I was referring to whether to continue in this report or whether to start a
> new one. I am guessing it's a similar but not identical bug.
> 
> (In reply to peter lawford from comment #12)
> > but a simple way to overcome the problem, if you don't want to turn off your
> > printer at each shutdown of your computer, and to turn on again after
> > computer's boot is to unplug the usb link of the printer and immediately
> > after to plug it in again
> 
> If the printer has just printed a test page why would turning it off and on
> again help?
> 
> Maybe I should have opened a new bug report as you must be on a different
> topic.

Does it work with printing a pdf file? I'm wondering if it's a problem
converting the ps to pdf.

Assigning to the registered maintainer for cups.

Assignee: bugsquad => thierry.vignaud

(In reply to Dave Hodgins from comment #20)
> Assigning to the registered maintainer for cups.

I have spent all today tracking this down and finally found that the fault is in the .ps generation in the latest pcb-rnd-3.1.1 package.

It misses the 'showpage' command at the end of the file. Hence the lack of error messages :\

I have reported this upstream and will update the pcb-rnd package after Mageia 9 release when a fix becomes available.

Thanks Peter and Dave for your suggestions :)

For me this is now INVALID so may be closed if the original issue is also fixed.

Severity: major => normal
Priority: High => Normal

Closing as invalid. Please reopen if the problem described in the description
can be recreated with some idea how to do so.

Assignee: thierry.vignaud => zen25000
Resolution: (none) => INVALID
Status: UNCONFIRMED => RESOLVED

(In reply to Barry Jackson from comment #9)
> I am also having issues with lp in Mga9 and Mga8.
> I have always used lp to print postscript files - the last time in Mga8 I
> used it was maybe six months ago or more so there have been updates since
> then.
> On attempting to print a .ps I see:
> ... 
> Then the printer just sits there for ever doing nothing.
> ...
> The print queue has the file apparently printing, so attempting to print
> anything else just fails as it's added to the queue.
(In reply to Barry Jackson from comment #21)
> I have spent all today tracking this down and finally found that the fault
> is in the .ps generation in the latest pcb-rnd-3.1.1 package.
> It misses the 'showpage' command at the end of the file. Hence the lack of
> error messages :\
This is very impressive detective work. Since the culprit you found is:
"Name        : pcb-rnd                                                          
Description :
pcb-rnd is a highly modular PCB (Printed Circuit Board) layout tool
with a rich set of plugins for communicating with various external
design tools and other EDA/CAD packages."

had you previously noticed any association with the source application? Meaning, did this blockage happen with .ps files from other sources?

Keywords: (none) => UPSTREAM

(In reply to Lewis Smith from comment #23)
> (In reply to Barry Jackson from comment #9)
> > I am also having issues with lp in Mga9 and Mga8.
> > I have always used lp to print postscript files - the last time in Mga8 I
> > used it was maybe six months ago or more so there have been updates since
> > then.
> > On attempting to print a .ps I see:
> > ... 
> > Then the printer just sits there for ever doing nothing.
> > ...
> > The print queue has the file apparently printing, so attempting to print
> > anything else just fails as it's added to the queue.
> (In reply to Barry Jackson from comment #21)
> > I have spent all today tracking this down and finally found that the fault
> > is in the .ps generation in the latest pcb-rnd-3.1.1 package.
> > It misses the 'showpage' command at the end of the file. Hence the lack of
> > error messages :\
> This is very impressive detective work. Since the culprit you found is:
> "Name        : pcb-rnd                                                      
> 
> Description :
> pcb-rnd is a highly modular PCB (Printed Circuit Board) layout tool
> with a rich set of plugins for communicating with various external
> design tools and other EDA/CAD packages."
> 
> had you previously noticed any association with the source application?
> Meaning, did this blockage happen with .ps files from other sources?

I only ever print .ps files exported from pcb-rnd for printed circuit work.
All .ps files from pcb-rnd view correctly in okular so I was not suspecting the files, especially as I had never seen a problem in many years of using pcb-rnd.
It was only when I created two functionally identical .ps files, one from pcb-rnd in Mageia 7.1 and one from Mageia 9 that I could see the difference.
This has now been fixed in upstream pcb-rnd and was a bug that occurred when printing a multi-file output (which I always do). The upstream automatic tests did not cover that situation :(