Bug 28715

Summary: Attempting to print a test page from system-config-printer with the boomaga virtual printer generates an error
Product: Mageia Reporter: Thomas Andrews <andrewsfarm>
Component: RPM PackagesAssignee: Thierry Vignaud <thierry.vignaud>
Status: NEW --- QA Contact:
Severity: normal    
Priority: Normal CC: davidwhodgins, fri
Version: 8   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: system-config-printer-1.5.15-1.mga8.src.rpm, cups-2.3.3op2-1.mga8.src.rpm CVE:
Status comment:
Attachments: Boomaga printer status screen before trying test print
Boomaga status windows after asking for test print

Description Thomas Andrews 2021-04-04 20:45:51 CEST
Description of problem:
If a user attempts to print a test page for the boomaga virtual printer from system-config-printer, an error is created. If the defaults have been applied, this error, like any error, stops the printer. The user, as root, must then clear the job and re-enable the printer before it will print anything from anywhere.

A workaround is to set the printer properties to "abort" the job if an error occurs. This of course does not fix the problem, but it avoids the consequences of it.

I don't know if there's something in boomaga that triggers this error, or if it is something in the test page. All I know is that I have yet to see boomaga generate an error like this with any other print job.
Morgan Leijström 2021-04-04 20:50:34 CEST

CC: (none) => fri

Comment 1 Jani Välimaa 2021-04-04 21:11:25 CEST
CUPS admin pages shows the following information after start printing test page.

"[Boomaga backend] ERROR: Can't get uid for user anonymous."
Comment 2 Lewis Smith 2021-04-04 21:45:47 CEST
This made me scratch my head; then explore.
Adding the Bommaga 'printer', after the long 'searching for drivers' step, it popped a small dialogue including a 'Print Test Page' button; clicking which, just said the job was queued. The higher-level window for the 'printer' showed this error:
"Idle - [Boomaga GUI] ERROR: Can't start boomaga gui."
Is this what you saw?
Screenshot of this situation to follow.

Right-clicking Bommaga to show its print queue took its time, but then showed the Q empty.
Printing from an application showed this same error under 'status' for the Boomaga printer in the print dialogue.
Reverting to the real printer, that printed a test page straight away, so that was not blocked.
I then disabled (Status -> Paused), then enabled the Boomaga printer, which cleared the error; after which the Boomaga 'printer' functioned correctly from an application.

So as TJ said, it is just printing a test page for the Bommaga printer that shows the error. Reproduceable.

CC: (none) => lewyssmith

Comment 3 Lewis Smith 2021-04-04 21:47:03 CEST
Created attachment 12574 [details]
Boomaga printer status screen before trying test print
Comment 4 Lewis Smith 2021-04-04 21:48:24 CEST
Created attachment 12575 [details]
Boomaga status windows after asking for test print
Comment 5 Lewis Smith 2021-04-04 21:55:28 CEST
@Jani : thanks for the insight comment 1 [I collided].
In the light of which, assigning to tv for CUPS.

Source RPM: (none) => system-config-printer-1.5.15-1.mga8.src.rpm, cups-2.3.3op2-1.mga8.src.rpm
Assignee: bugsquad => thierry.vignaud

Lewis Smith 2021-04-04 21:55:41 CEST

CC: lewyssmith => (none)

Comment 6 Dave Hodgins 2021-04-04 23:20:26 CEST
Experimented a bit. In localhost:631, selected Printers, clicked on the Boomaga
printer, selected Administration/Set Allowed Users, entered my login (dave),
selected the option Allow these users to print, and selected the "Set Allowed Users" button.
After canceling the prior jobs, and printing the test page, the error is now
"[Boomaga GUI] ERROR: Can't start boomaga gui."

Found it's reported already at
https://github.com/Boomaga/boomaga/issues/102

Printing a document from oowriter, selecting the boomaga printer is working
to open boomaga with the document showing.

I suspect it's that the user printing must be set as allowed, and the application
be run by the user who owns the desktop session.

So the user printing the document must be specified as allowed in cups, and that
user has to be running the application doing the printing. As cups is run by
root, the test page fails.

Not necessarily bugs, other then perhaps lacking clear documentation.

CC: (none) => davidwhodgins