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