Bug#982925: libgtk: print dialog lists autodetected printer twice

[Simon McVittie]

On Tue, 16 Feb 2021 at 11:55:28 -0500, Zack Weinberg wrote:
> I have only one printer, a network-attached Brother HL model.  CUPS
> autodetects it somehow and creates a queue for it:
> 
> $ lpstat -e
> Brother_HL_L2350DW_series
> 
> This queue shows up twice in the GTK print dialog box, with two
> slightly different names (see attached screenshot).
> 
> This is not merely a cosmetic problem: only one of the two queues
> actually works.  If I select the wrong one, the print job disappears
> into the aether.

On Mon, 26 Jul 2021 at 02:24:06 +0200, Daniel Gröber wrote:
> I was seeing the exact same problem
(and on a merge request)
> Printers discovered directly via avahi instead of going through cups
> don't always work properly, in my case printing to such a printer will
> just keep spewing pages filled with binary garbage until the print job
> is cancelled manually.

That doesn't appear to be the exact same problem: Zack said that printing
just doesn't happen, but Daniel said that printing produces a wrong
print job.

I have been looking into Daniel's merge request [!9], and a related
merge request that backports the entire CUPS printing module from GTK
3.24.29 [!6], trying to figure out which one is the better candidate
for a stable update.

[!6]: https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/6
[!9]: https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/9

At the moment, I am leaning towards the more complete !6 being a better
candidate for a stable update, even though it is technically a feature
enhancement, which we don't usually do in stable. Please could you try the
release candidate from here, and confirm whether it solves the issues you
are seeing?
    https://people.debian.org/~smcv/bullseye-gtk-printing/mr6/

The _binary.changes and .dsc files are signed with my key in the Debian
keyring, and can be verified with the dscverify tool from the devscripts
package (this requires devscripts and debian-archive-keyring installed).

If the release team will not accept !6, then the fallback option is !9,
which is the change that Daniel proposed:
    https://people.debian.org/~smcv/bullseye-gtk-printing/mr9/

I would appreciate test results from both of these if possible.

When reporting test results, please answer these questions:

* Which versions of cups-daemon and cups-filters-core-drivers are installed?
* How many printers are physically present on your network?
* Have you configured a printer queue in CUPS manually, or are you only
  using auto-detection?
* Is cups-browsed installed? If yes, which version?
* What printer names appear in the GTK print dialog?
  (If they contain MAC addresses or serial numbers, you can censor them
  as XXXXXX)
* For each printer name that appears:
  * Does printing to it work?
  * If not, what failure mode do you see?
    (Nothing happens / printer prints wrong results / other)

I will reply to the bug with my own test results.

    smcv