Bug#982925: Request for testing: GTK for bullseye with improved CUPS printing support

[Simon McVittie]

On Fri, 25 Feb 2022 at 08:25:44 +0000, Jaycee Santos wrote:
> I am unable to print anything through the network with mr6.1 and mr9.1, but
> printing through USB still works fine.

Wait, how is this printer connected? I thought we were talking about
networked printers connected to your LAN. Is this one directly connected
to your computer with USB? Or is it both?

Please could you try again with the official version of GTK from
Debian 11, so that we can see whether this is a regression?

It would probably also be useful to compare the results with a Qt
application: I used the leafpad package (from LXQT) as my example while
testing this. My goal in preparing GTK 3.24.24-4+deb11u2~mr6.1 was to
make its behaviour consistent with Qt, which other people have been saying
is better at successful printing in bullseye.

I hope this demonstrates to anyone asking "why can't you just?" why I'm
being so cautious about applying the patches that people have proposed:
a change that is an improvement for someone can be a regression for
someone else.

> 3.24.24-4+deb11u2~mr6.1
> =======================
> > * For each printer name that appears:
> >  * Does it appear in /etc/cups/printers.conf?
> HP_ENVY_5000_series_XXXXXX_                      yes
> HP_ENVY_5000_series_XXXXXX_ at HPXXXXXXXXXXXX.local yes
> HP_ENVY_5000_series_XXXXXX_USB_                  yes
> >  * Does printing to it work?
> HP_ENVY_5000_series_XXXXXX_                      no
> HP_ENVY_5000_series_XXXXXX_ at HPXXXXXXXXXXXX.local no
> HP_ENVY_5000_series_XXXXXX_USB_                  yes

I think this means that the code I changed in GTK is matching the naming
of the printers detected by cups-browsed, as intended, so that the printers
detected by cups-browsed are treated as "more important" and take
precedence.

Unfortunately, in your case, the printer detection by cups-browsed results
in some queues that don't actually work, breaking GTK's assumption that
if cups tells it that a printer exists, then GTK should get out of the
way and only display the one cups announced, not the one GTK detected.

With the latest upstream version of GTK in testing/unstable, I think you
would see the same results as this, but without the last underscore after
the serial number (HP_ENVY_5000_series_XXXXXX and so on).

> >  * If not, what failure mode do you see?
>     (Nothing happens / printer prints wrong results / other)
> HP_ENVY_5000_series_XXXXXX_                      nothing happens
>                                                  (status is: "Printer
>                                                  disappeared or cups-browsed
>                                                  shutdown")
> HP_ENVY_5000_series_XXXXXX_ at HPXXXXXXXXXXXX.local nothing happens
>                                                  (status is: "Paused")

I think you will need to talk to people who actually know about printing
(not me) on a separate bug report in order to resolve this.

> 3.24.24-4+deb11u2~mr9.1
> =======================

(same results as above, probably for the same reasons)

> 3.24.24-4+deb11u2~mr6
> =====================
> > * For each printer name that appears:
> >  * Does it appear in /etc/cups/printers.conf?
> HP_ENVY_5000_series_XXXXXX                       no
> HP_ENVY_5000_series_XXXXXX_                      yes
> HP_ENVY_5000_series_XXXXXX_ at HPXXXXXXXXXXXX.local yes
> HP_ENVY_5000_series_XXXXXX_USB                   no
> HP_ENVY_5000_series_XXXXXX_USB_                  yes
> >  * Does printing to it work?
> HP_ENVY_5000_series_XXXXXX                       yes
> HP_ENVY_5000_series_XXXXXX_                      no
> HP_ENVY_5000_series_XXXXXX_ at HPXXXXXXXXXXXX.local no
> HP_ENVY_5000_series_XXXXXX_USB                   yes
> HP_ENVY_5000_series_XXXXXX_USB_                  yes

Unfortunately, I think what you have here is one bug acting as a
workaround for another bug.

When the version of cups-browsed in bullseye translates mDNS service
names into cups print queue names, it does not remove the trailing ")"
(which turns into a trailing "_" in the cups print queue name).

When the newer version of cups-browsed in testing/unstable does the same
translation into cups print queue names, it *does* remove the trailing
")" (or "_") from the name. The upstream GTK code in testing/unstable
matches the behaviour of this newer cups-browsed. Proposed backports
3.24.24-4+deb11u2~mr6 and 3.24.24-4+deb11u2~mr9 are also consistent
with this.

If GTK and cups-browsed do not agree on what the rule is for this
translation, then you get "duplicate" (actually near-duplicate) printers.
The one with the trailing "_" is from cups, the one without the "_" is
from GTK.

GTK 3.24.24-4+deb11u2~mr6.1 and 3.24.24-4+deb11u2~mr9.1 adjust the rule
for this translation to be consistent with bullseye's cups-browsed, with
the intention to eliminate the duplicate printer names.

Daniel Gröber reported seeing a similar thing, but for him, the queue
created by cups-browsed was the one that works, and the queue created
by GTK was the one that does not work. That meant that eliminating GTK's
"duplicate" results in things working better for him (as well as being
less confusing). Similarly, for me, removing the duplicates was an
improvement.

For you, the opposite is true: GTK's "duplicate" print queues actually
work fine, but some of the ones created by cups-browsed (which the
upstream GTK code assumes to be "better") do not.

    smcv