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

[Brian Potkin]

On Sun 13 Mar 2022 at 14:38:13 +0100, Daniel Gröber wrote:

[...]

> Here I also don't quite understand libgtk upstream. I assume the intention
> for the fallback is to have printing to at least work with some printers
> when cups isn't running/installed. While I think that's a terrible idea we
> still didn't want to break that behaviour since some users might now be
> depending on it.

There are users who depend on GTK's non-CUPS behaviour? Heaven help
them! They are expecting an experience divorced from what the the
printing system provides. They will possibly be shocked when using
bookworm.

The one thing GTK did correctly on buster and bullseye was handle
the shared queues of remote CUPS servers. On bookworm these are are
now inaccessible. A regression in its so-called "fallback" status?
I do not think I will lose much sleep over this :).

Regards,

Brian.

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

[Brian Potkin]

On Sun 13 Mar 2022 at 17:07:19 +0100, d...@darkboxed.org wrote:

> On Sun, Mar 13, 2022 at 04:03:44PM +, Brian Potkin wrote:
> > Printing via a GTK destination to an IPP printer has never worked for
> > me. Even if printer information could be obtained, a Cairo-produced PDF
> > would go to the printer and PDF is not a PDL understood by it. In what
> > circumstances does such a destination work?
> 
> Believe it or not, some printers will actually accept straight up PDFs
> being piped into them without a PDL wrapper.

Hello Daniel,

I am unfamiliar with the term "PDL wrapper". Your input would be
welcome to clarify this.

I fully accept that a PDF sent *directly* to a printer with a PDF
interpreter should be printed. Are you saying the GTK dialog is
using this technique? Is this from obervation with your IPP printer?

Regards,

Brian.

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

[dxld]

On Sun, Mar 13, 2022 at 04:03:44PM +, Brian Potkin wrote:
> Printing via a GTK destination to an IPP printer has never worked for
> me. Even if printer information could be obtained, a Cairo-produced PDF
> would go to the printer and PDF is not a PDL understood by it. In what
> circumstances does such a destination work?

Believe it or not, some printers will actually accept straight up PDFs
being piped into them without a PDL wrapper.

--Daniel


signature.asc
Description: PGP signature

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

[Brian Potkin]

On Sun 13 Mar 2022 at 14:38:13 +0100, Daniel Gröber wrote:

> Hi Brian and Simon,
> 
> On Sat, Mar 12, 2022 at 08:56:38PM +, Brian Potkin wrote:
> > You have just confirmed that the printing system (CUPS + cups-filters
> > + (optionally) cups-browsed) works effieiently and as designed.
> > 
> > > Resultion: printing is still hell on earth :]
> > 
> > libgtk is not part of the printing system; 
> 
> Erm, sorry but it is part of the printing experience from a user's POV.

True.
 
> I wasn't trying to imply cups is the problem in fact if you read the
> backlog much of my frustration is with libgtk, but hell at least I'm here
> proposing patches so I feel I get to poke som fun at it. No offence
> intended Simon :)
> 
> Besides in the end it turned out libgtk with the right patch does work so
> *shrug*.

Having the GTK dialog on bullseye as a good citizen would be gratifying.
 
> > > - Printing via libgtk's fallback entry always fails
> > 
> > I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> > needed when the printing system does the jobi, as you have demonstrated?
> > On bullseye libgtk treads its own path and ignores the CUPS APIs. It is
> > little wonder users (like the bug submitter) experience consternation.
> 
> Here I also don't quite understand libgtk upstream. I assume the intention
> for the fallback is to have printing to at least work with some printers
> when cups isn't running/installed. While I think that's a terrible idea we
> still didn't want to break that behaviour since some users might now be
> depending on it.

I cannot provide code but can supply information. Perhaps there is some
enlightenment at

  https://bugzilla.gnome.org/show_bug.cgi?id=688956

This is what began the process. Comments 5 and 6 look interesting.

Printing via a GTK destination to an IPP printer has never worked for
me. Even if printer information could be obtained, a Cairo-produced PDF
would go to the printer and PDF is not a PDL understood by it. In what
circumstances does such a destination work?

Regards,

Brian.

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

[Daniel Gröber]

Hi Brian and Simon,

On Sat, Mar 12, 2022 at 08:56:38PM +, Brian Potkin wrote:
> You have just confirmed that the printing system (CUPS + cups-filters
> + (optionally) cups-browsed) works effieiently and as designed.
> 
> > Resultion: printing is still hell on earth :]
> 
> libgtk is not part of the printing system; 

Erm, sorry but it is part of the printing experience from a user's POV.

I wasn't trying to imply cups is the problem in fact if you read the
backlog much of my frustration is with libgtk, but hell at least I'm here
proposing patches so I feel I get to poke som fun at it. No offence
intended Simon :)

Besides in the end it turned out libgtk with the right patch does work so
*shrug*.

> > - Printing via libgtk's fallback entry always fails
> 
> I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> needed when the printing system does the jobi, as you have demonstrated?
> On bullseye libgtk treads its own path and ignores the CUPS APIs. It is
> little wonder users (like the bug submitter) experience consternation.

Here I also don't quite understand libgtk upstream. I assume the intention
for the fallback is to have printing to at least work with some printers
when cups isn't running/installed. While I think that's a terrible idea we
still didn't want to break that behaviour since some users might now be
depending on it.

--Daniel


signature.asc
Description: PGP signature

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

[Brian Potkin]

On Sat 12 Mar 2022 at 23:35:25 +, Simon McVittie wrote:

> On Sat, 12 Mar 2022 at 20:56:38 +, Brian Potkin wrote:
> > I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> > needed when the printing system does the jobi, as you have demonstrated?
> 
> cups upstream's medium to long term plan seems to be that toolkits like
> GTK and Qt should browse for mDNS printers themselves, and cups-browsed
> will eventually disappear, so that the only print queues shown are the
> ones manually configured in cups and the ones auto-discovered by the
> toolkits' print dialogs:
> 
> The intention of CUPS upstream is that the application's print dialogs
> browse the Bonjour broadcasts as an AirPrint-capable iPhone does,
> but it will take its time until all toolkit developers add the needed
> functionality, and programs using old toolkits or no toolkits at all,
> or the command line stay uncovered.
> — https://github.com/OpenPrinting/cups-filters

The github text is in /usr/share/doc/cups-filters/README.gz. Note that
it dates from the time of CUPS 1.6 when CUPS could not browse DND-SD
multicasts of CUPS servers and printers, and therefore would not make
queues and printers available locally. cups-browsed became essential
to do this. Without it, printing to a metwork queue would have been
tortuous, if not impossibel.
 
> In bullseye, cups-browsed is usually installed on desktop systems. The
> intention seems to be that the printers discovered by cups-browsed take
> precedence over the ones discovered by GTK, but in current bullseye this
> doesn't work reliably, and instead both sets appear as near-duplicates
> (see below).

Since CUPS 1.6 the need for cups-browsed has effectively disappeared.
Its major use now is to provide auto-setup of a local queue.

However, on bullseye, the GTK dialog  is not using the correct CUPS APIs
and queues have to be manually created or auto-setup by cups-browsed.

 
> In bullseye, if you print to the entries generated by GTK from mDNS,
> then GTK will submits a PDF via IPP directly to the printer, bypassing
> cups (and that doesn't always work, as seen here). In the implementation
> in bookworm, backported here as the versions with ~mr6 or ~mr6.1 in
> their names, GTK's fallback entries are implemented by asking the local
> instance of cups to set up a temporary print queue, and then submitting
> the job via IPP to that temporary queue, which seems to be more reliable
> in practice.

bookworm's libgtk does a much better job than buster's or bulleye's. On
bullseye the dialog displays "getting printer information" and never
does.

> So, if you think cups is always going to be better at IPP than GTK is,
> I hope you would agree that the ~mr6 or ~mr6.1 versions, which make more
> use of cups than the version currently in bullseye, are a better answer
> than what GTK in bullseye is currently doing?

I do agree with that.
 
> If the response to asking for testing of possible improvements is going
> to be people characterizing GTK as irretrievably inept, then that is
> not going to help me to find the time and motivation to work on making
> things better (the opposite, in fact).

I did not say or imply the situation was "irretrievable". I did use
"inept"; "suboptimal" might have been better :).

> In particular, if the changes I'm proposing are bringing GTK closer to
> what you want, which I think they are, then it seems counterproductive to
> discourage me from making them. Conversely, if you think these changes are
> wrong, please focus on proposing solutions rather than ascribing blame:
> that's a much more effective way to motivate volunteers to do as you ask.
> 
> > If I set up a manual destination, I would be extremely annoyed if it was
> > interfered with.
> 
> I believe the intention is that if there is a manually-configured queue,
> then any automatically-discovered entries that can be identified as being
> the same printer are ignored.

If you are referring to cups-browsed, that is correct.

> Also, if there is no manually-configured queue, but there is an
> automatically-discovered entry from cups-browsed, then the intention
> is that GTK uses that one, and any entries discovered by GTK that can
> be identified as the same printer are ignored. So as far as I can
> tell, it's aiming to do what you want: manual configuration "wins"
> vs. auto-detection, and cups-browsed's auto-detection "wins" vs. GTK's,
> so in each case, GTK is aiming to prioritize the cups printing system
> higher than its own code path.

cups-browsed is not required with the GTK dialog in bookworm. #908500.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908500

> The reason we're seeing duplicates seems to be that they are not always
> identified as being the same printer in the way that was intended. In
> the implementation of that deduplication in bullseye's GTK, entries for
> the same printer are not always identified as such, so you're offered
> the result of 

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

[Simon McVittie]

On Sat, 12 Mar 2022 at 20:56:38 +, Brian Potkin wrote:
> I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> needed when the printing system does the jobi, as you have demonstrated?

cups upstream's medium to long term plan seems to be that toolkits like
GTK and Qt should browse for mDNS printers themselves, and cups-browsed
will eventually disappear, so that the only print queues shown are the
ones manually configured in cups and the ones auto-discovered by the
toolkits' print dialogs:

The intention of CUPS upstream is that the application's print dialogs
browse the Bonjour broadcasts as an AirPrint-capable iPhone does,
but it will take its time until all toolkit developers add the needed
functionality, and programs using old toolkits or no toolkits at all,
or the command line stay uncovered.
— https://github.com/OpenPrinting/cups-filters

In bullseye, cups-browsed is usually installed on desktop systems. The
intention seems to be that the printers discovered by cups-browsed take
precedence over the ones discovered by GTK, but in current bullseye this
doesn't work reliably, and instead both sets appear as near-duplicates
(see below).

In bullseye, if you print to the entries generated by GTK from mDNS,
then GTK will submits a PDF via IPP directly to the printer, bypassing
cups (and that doesn't always work, as seen here). In the implementation
in bookworm, backported here as the versions with ~mr6 or ~mr6.1 in
their names, GTK's fallback entries are implemented by asking the local
instance of cups to set up a temporary print queue, and then submitting
the job via IPP to that temporary queue, which seems to be more reliable
in practice.

So, if you think cups is always going to be better at IPP than GTK is,
I hope you would agree that the ~mr6 or ~mr6.1 versions, which make more
use of cups than the version currently in bullseye, are a better answer
than what GTK in bullseye is currently doing?

If the response to asking for testing of possible improvements is going
to be people characterizing GTK as irretrievably inept, then that is
not going to help me to find the time and motivation to work on making
things better (the opposite, in fact).

In particular, if the changes I'm proposing are bringing GTK closer to
what you want, which I think they are, then it seems counterproductive to
discourage me from making them. Conversely, if you think these changes are
wrong, please focus on proposing solutions rather than ascribing blame:
that's a much more effective way to motivate volunteers to do as you ask.

> If I set up a manual destination, I would be extremely annoyed if it was
> interfered with.

I believe the intention is that if there is a manually-configured queue,
then any automatically-discovered entries that can be identified as being
the same printer are ignored.

Also, if there is no manually-configured queue, but there is an
automatically-discovered entry from cups-browsed, then the intention
is that GTK uses that one, and any entries discovered by GTK that can
be identified as the same printer are ignored. So as far as I can
tell, it's aiming to do what you want: manual configuration "wins"
vs. auto-detection, and cups-browsed's auto-detection "wins" vs. GTK's,
so in each case, GTK is aiming to prioritize the cups printing system
higher than its own code path.

The reason we're seeing duplicates seems to be that they are not always
identified as being the same printer in the way that was intended. In
the implementation of that deduplication in bullseye's GTK, entries for
the same printer are not always identified as such, so you're offered
the result of GTK's mDNS discovery *in addition to* the one from cups,
instead of having the one from cups replace it. The changes between
bullseye and bookworm (proposed here as the ~mr6 and ~mr6.1 versions)
change the deduplication so that the duplicates coming from GTK's own
mDNS discovery are eliminated more reliably.

The code in the ~mr6 version (which is a direct backport from bookworm)
appears to be correct for bookworm's cups-browsed but not for bullseye's,
because the different versions of cups-browsed choose slightly different
names for mDNS-advertised printers. The change between ~mr6 and ~mr6.1
adjusts the naming used by GTK to match bullseye's cups-browsed, so
that the version coming from cups-browsed will "win" and replace what
GTK would have done in the absence of cups-browsed.

If you have a better implementation of this, great! Please talk to
upstream, preferably without insulting them ("these changes would make
xyz more reliable" is more likely to get the changes accepted than
"your implementation of xyz is awful and you should use this instead",
even if the resulting code is identical).

> Problem: it does not live up to its promises and hasn't for
> many years. It is inept.

Even if true, this is not an effective way to make volunteers do what
you say they should. At best, it's demoralizing 

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

[Brian Potkin]

On Sat 26 Feb 2022 at 19:43:08 +0100, Daniel Gröber wrote:

> Here are my test results:
> 
> TLDR:
> 
> - Printing via cups entry (be that cups-browsed or manual) always succeeds

You have just confirmed that the printing system (CUPS + cups-filters
+ (optionally) cups-browsed) works effieiently and as designed.
> 
> - Printing via libgtk's fallback entry always fails

I wouldn't see libgtk as providing a fallbac. Why would a fallback be
needed when the printing system does the jobi, as you have demonstrated?
On bullseye libgtk treads its own path and ignores the CUPS APIs. It is
little wonder users (like the bug submitter) experience consternation.

If it wasn't for cups-bowsed, we would be overrun with bug reports.
> 
> - Both proposed fixes work and succeed in removing the duplicate entry for
>   cups-browsed, but not for a manually added printer with default name or
>   when the user chooses a name that doesn't match the cups-browsed/libgtk
>   mangling scheme.

If I set up a manual destination, I would be extremely annoyed if it was
interfered with.

> Resultion: printing is still hell on earth :]

libgtk is not part of the printing system; it is a helper program. It
says - here are some destinations, click on them and I will do your
prinring. Problem: it does not live up to its promises and hasn't for
many years. It is inept. So let's have the source of this bug on
bullseye correectly and fairly and squarly identified. It is libgtk.
That is your hell :).

BTW, whoever said Qt is more competent hasn't looked at how it behaves
without cups-browsed.

With thanks to Simon McVittie and everyone else for caring.

Regards,

Brian.

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

[dxld]

Addendum:

I've had another closer look at the temporary queues code and upstream
discussions and I seem to have neglected the most significant configuration
for mr6.1. Namely "without cups-browsed or manual config". This in fact
works now because libgtk specifically doesn't try to just send garbage to
the printer anymore but actually does it via cups by creating a temporary
printer which gets removed after some inactivity.

The queue creation seems to be inhibited only if a manually added printer
of just the right name already exists.

On Sat, Feb 26, 2022 at 07:43:10PM +0100, Daniel Gröber wrote:
> Here are my test results:
> With mr6.1 and cups-browsed auto-detection:
> 
> Brother_HL_L5100DN_series (works)
> 
> With mr6.1, cups manual config and default name[1]:
> 
> Brother_HL-L5100DN_series_ (works)
>   Brother_HL_L5100DN_series (Status: Rejecting jobs, won't print)
> 
> With mr6.1, cups manual config and corrected name[1]:
> 
>   Note: Here we use all underscores in the configured printer name to
>   make the merging logic trigger.
> 
>   Brother_HL_L5100DN_series (works)
> 
> With mr6.1, both cups manual and cups-browsed auto-config and corrected 
> name[1]
> 
> Brother_HL_L5100DN_series (cups manual, works)
> Brother_HL_L5100DN_series@brother-hl-l5100dn.local (cups-browsed, 
> works)   

 With mr6.1, cups installed, no cups-browsed, no manual config:
 
 Brother_HL_L5100DN_series (cups temporary queue, works)

I'm also not sure what was up with the (manual+default name)
configuration. I tried again and now the libgtk temporary queue entry
prints just fine too:

 With mr6.1, cups manual config and default name[1]:
 
Brother_HL-L5100DN_series_ (works)
Brother_HL_L5100DN_series (works)

I was able to reproduce the "Rejecting Jobs" outcome a couple of times, but
not reliably.

Together with picking the right printer name I was once able to get into a
state where the rejecting print entry is the only one (: Trying to resume
the temporary queue in the cups web interface also didn't help with that.

So there is still some potential for improvement here but I agree mr6.1 is
the way to go if we want printing to work in more cases than currently.

--Daniel


signature.asc
Description: PGP signature

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

[Daniel Gröber]

Here are my test results:

TLDR:

- Printing via cups entry (be that cups-browsed or manual) always succeeds

- Printing via libgtk's fallback entry always fails

- Both proposed fixes work and succeed in removing the duplicate entry for
  cups-browsed, but not for a manually added printer with default name or
  when the user chooses a name that doesn't match the cups-browsed/libgtk
  mangling scheme.

Resultion: printing is still hell on earth :]



 * Which versions of cups-daemon and cups-filters-core-drivers are installed?

cups-filters-core-drivers   1.28.7-1
cups-daemon 2.3.3op2-3+deb11u1

 * Is cups-browsed installed? If yes, which version?

cups-browsed1.28.7-1

 * How many printers are physically present on your network?

One Brother HL-L5100DN

 * Have you configured a printer queue in CUPS manually, or are you only
   using auto-detection?
 * What printer names appear in the GTK print dialog?
 * For each printer name that appears:

With libgtk-3-0 =3.24.24-4 from bullsye, no cups, no browsed:

Brother-HL-L5100DN-series (prints garbage)

With libgtk-3-0 =3.24.24-4 from bullsye and cups-browsed auto-detection:

Brother-HL-L5100DN-series (prints garbage)
Brother_HL_L5100DN_series (works)

With libgtk-3-0 =3.24.24-4, cups manual config and default name[1]:

Brother-HL-L5100DN-series (prints garbage)
Brother_HL-L5100DN_series_ (works)

With libgtk-3-0 =3.24.24-4, cups manual config and corrected name[1]:

Note: with =3.24.24-4 the printer name has to be corrected to match
the all dash version for the merging logic to trigger so that what
we do here.

Brother-HL-L5100DN-series (works)

  Note: I call the entry that appears without cups/browsed the "fallback
  entry". The libgtk code doesn't do any sort of print job
  formatting/filtering that I could find just sending whatever internal
  representation libgtk uses (probably PDF) towards the printer hoping for
  the best.



With mr6.1 and cups-browsed auto-detection:

Brother_HL_L5100DN_series (works)

With mr6.1, cups manual config and default name[1]:

Brother_HL-L5100DN_series_ (works)
Brother_HL_L5100DN_series (Status: Rejecting jobs, won't print)

With mr6.1, cups manual config and corrected name[1]:

Note: Here we use all underscores in the configured printer name to
make the merging logic trigger.

Brother_HL_L5100DN_series (works)

With mr6.1, both cups manual and cups-browsed auto-config and corrected 
name[1]

Brother_HL_L5100DN_series (cups manual, works)
Brother_HL_L5100DN_series@brother-hl-l5100dn.local (cups-browsed, 
works)   



With mr9.1 and cups-browsed auto-detection:

Brother_HL_L5100DN_series (works)

With mr9.1, cups manual config and default name[1]:

Brother_HL-L5100DN_series_ (works)
Brother_HL_L5100DN_series (prints garbage)

With mr9.1, cups manual config and corrected name[1]:

Note: Here we use all underscores in the configured printer name to
make the merging logic trigger.

Brother_HL_L5100DN_series (works)

With mr9.1, both cups manual and cups-browsed auto-config and corrected 
name[1]

Brother_HL_L5100DN_series (cups manual, works)
Brother_HL_L5100DN_series@brother-hl-l5100dn.local (cups-browsed, works)


[1] About the cups default/corrected name:

cups puts a dash in HL-L5100DN and adds a trailing underscore to the
default name compared to cups-browsed auto configured name so merging of
the entries doesn't work if defaults are accepted.

Cups setup procedure:

apt-get purge 'cups-*'; rm -rf /etc/cups
apt-get install cups   (for cups-browse)
apt-get install cups --no-install-recommends   (no cups-browsed)

Manually adding printer via cups webinterface:

[Find New Printers]
 -> Brother HL-L5100DN series (Brother HL-L5100DN series (driverless))
 -> Name: Brother_HL-L5100DN_series_ (in default case)
 -> Make: Brother, Model: {current_make_and_model} - IPP Everywhere ^{TM}
 -> [Add Printer]

 * What printer names are listed in /etc/cups/printers.conf?

For cups-browsed:

 
(when manually configured printer would conflict)

For manual config:
 (default)
 (corrected for =3.24.24-4)
 (corrected for mr{6,}.1)

--Daniel


signature.asc
Description: PGP signature

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

[Simon McVittie]

On Mon, 21 Feb 2022 at 22:20:31 +0100, d...@darkboxed.org wrote:
> I'll make some time this weekend to test both versions. Should be pretty
> quick as long as you don't need test results for a clean system -- do you?

The more testing you can do, the better, but upgrading the packages on
an existing system is a lot better than nothing.

Priority order (if you can only try a subset, I'd prefer you to try the
ones earlier in this list as a higher priority):

0. What's in bullseye right now, as a baseline

1. https://people.debian.org/~smcv/bullseye-gtk-printing/mr6.1/
   (the more complete backport, adjusted for better interop with bullseye's
   cups-browsed with certain printer names like mine)

2. https://people.debian.org/~smcv/bullseye-gtk-printing/mr9.1/
   (your more minimal backport, again adjusted for better interop with
   bullseye's cups-browsed)

3. https://people.debian.org/~smcv/bullseye-gtk-printing/mr6/
   and https://people.debian.org/~smcv/bullseye-gtk-printing/mr9/
   (only worth doing if you see strange results from the others and want
   to compare)

Thanks,
smcv

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

[dxld]

Hi Simon,

Thanks for working on this, I do appreciate it :)

On Sun, Feb 20, 2022 at 05:19:32PM +, Simon McVittie wrote:
> On Mon, 26 Jul 2021 at 02:24:06 +0200, Daniel Gröber wrote:
> > I was seeing the exact same problem
> 
> 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.

That's probably not a symptom of the bug and just differing behavour of the
printers when presented with garbage input they don't understand.

AFAICT from the code, in the code-path where libgtk doesn't print via cups
no print-job filtering/reformatting happens at all but rather the plain pdf
is just piped stright to the print queue so that's not really surprising :)

> 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 XX)
> * 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'll make some time this weekend to test both versions. Should be pretty
quick as long as you don't need test results for a clean system -- do you?

--Daniel



signature.asc
Description: PGP signature

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

[Simon McVittie]

Here is hopefully a better solution for GTK 3 in bullseye:

https://people.debian.org/~smcv/bullseye-gtk-printing/mr6.1/

or if the release team will not accept that, then this:

https://people.debian.org/~smcv/bullseye-gtk-printing/mr9.1/

Please try those (in preference to mr6, mr9) and see what happens with
your particular printers.

As before, 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).

Test results below.

smcv

> * Which versions of cups-daemon and cups-filters-core-drivers are installed?

cups-daemon 2.3.3op2-3+deb11u1
cups-filters-core-drivers   1.28.7-1

> * How many printers are physically present on your network?

One HP Color LaserJet MFP M277dw.

> * Is cups-browsed installed? If yes, which version?

I tested both with and without cups-browsed 1.28.7-1.

Test methodology for each of the 8 attempts listed here (I'm using an
expendable test machine, do not do these steps unless you are willing
to lose manual CUPS configuration):

sudo apt purge cups-browsed cups-daemon
sudo rm -fr /etc/cups
sudo apt install cups cups-core-drivers cups-daemon cups-browsed-
(optionally) Configure printer: gnome-control-center, Printers, Unlock,
 Add..., wait, click on the single printer that appears, Add
(optionally) sudo apt install cups-browsed
gedit
Try to print

GTK 3.24.24-4 (status quo in bullseye)
==

Repeating my previous test results for reference:

| cups-browsed installed |
|no  | yes   |
||---|
printer manually configured   no|unavailable | works |
 yes| works  |duplicated |
||---|

GTK based on merge request 6 (full backport from 3.24.29)
=

| cups-browsed installed |
|no  | yes   |
||---|
printer manually configured   no| works  | works |
 yes| works  | works |
||---|

With no configuration and no cups-browsed: One printer appears in the
GTK dialog, labelled HP_Color_LaserJet_MFP_M277dw_xx_. It is not
listed in /etc/cups/printers.conf. Printing is successful.

With cups-browsed only: One printer appears, labelled
HP_Color_LaserJet_MFP_M277dw_xx_.
It is listed in /etc/cups/printers.conf, labelled as having come from
cups-browsed. It prints successfully.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.
(This is actually better than the Qt app featherpad, which displays two
printers in this situation.)

With both: Same as with manual configuration only.

GTK based on merge request 9 (Daniel's minimal backport)


| cups-browsed installed  |
|no  | yes|
|||
printer manually configured   no| works  | works  |
 yes| works  | duplicated |
|||

With no configuration and no cups-browsed: One printer appears in the
GTK dialog, labelled HP_Color_LaserJet_MFP_M277dw_xx_. It is not
listed in /etc/cups/printers.conf. Printing is successful.

With cups-browsed only: One printer, HP_Color_LaserJet_MFP_M277dw_xx_,
where xx is a unique ID taken from its MAC address. It is in
/etc/cups/printers.conf. Printing is successful.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.

With both: both of the printers mentioned above appear in the GTK dialog
and in /etc/cups/printers.conf. Only the first one printed successfully:
the second logged "NO_DEST_FOUND".

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

[Simon McVittie]

On Sun, 20 Feb 2022 at 17:35:23 +, Simon McVittie wrote:
> GTK with merge request 6 (full backport from 3.24.29)
...
> With cups-browsed only: Two printers appear, labelled
> HP_Color_LaserJet_MFP_M277dw_xx and HP_Color_LaserJet_MFP_M277dw_xx_.

This seems to be a mismatch between the transformation from DNS-SD
name in recent versions of cups-browsed (for which modern GTK's code is
correct) and older versions of cups-browsed such as the one in Debian 11
(for which an additional patch is needed). I'm now preparing variants
of merge requests 6 and 9 that have this additional patch.

smcv

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

[Simon McVittie]

On Sun, 20 Feb 2022 at 17:35:23 +, Simon McVittie wrote:
> With cups-browsed only: Two printers appear, labelled
> HP_Color_LaserJet_MFP_M277dw_xx and HP_Color_LaserJet_MFP_M277dw_xx_.

I think this is because the mDNS name of my printer happens to end with
a parenthesis (it's "HP Color LaserJet MFP M277dw (xx)"), and with
this specific printer, the algorithms used by GTK and cups-browsed to
flatten mDNS names into syntactically-valid printer names are subtly
different: GTK removes trailing invalid characters, but cups-browsed
does not (this appears to be deliberate, it has special code to do this
for other strings but not for DNS-SD-based printer names).

smcv

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

[Simon McVittie]

On Sun, 20 Feb 2022 at 17:19:32 +, Simon McVittie wrote:
> 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 XX)
> * 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)

Sorry, I should have mentioned another question:

* What printer names are listed in /etc/cups/printers.conf?

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

[Simon McVittie]

On Sun, 20 Feb 2022 at 17:19:36 +, Simon McVittie wrote:
> I will reply to the bug with my own test results.

> * Which versions of cups-daemon and cups-filters-core-drivers are installed?

cups-daemon 2.3.3op2-3+deb11u1
cups-filters-core-drivers   1.28.7-1

> * How many printers are physically present on your network?

One HP Color LaserJet MFP M277dw.

> * Is cups-browsed installed? If yes, which version?

I tested both with and without cups-browsed 1.28.7-1.

Test methodology for each of the 12 attempts listed here (I'm using an
expendable test machine, do not do these steps unless you are willing
to lose manual CUPS configuration):

sudo apt purge cups-browsed cups-daemon
sudo rm -fr /etc/cups
sudo apt install cups cups-core-drivers cups-daemon cups-browsed-
(optionally) Configure printer: gnome-control-center, Printers, Unlock,
 Add..., wait, click on the single printer that appears, Add
(optionally) sudo apt install cups-browsed
G_MESSAGES_DEBUG=all gedit
Try to print

GTK 3.24.24-4 (status quo in bullseye)
==

| cups-browsed installed |
|no  | yes   |
||---|
printer manually configured   no|unavailable | works |
 yes| works  |duplicated |
||---|

With no configuration and no cups-browsed: No printers are listed

With cups-browsed only: One printer, HP_Color_LaserJet_MFP_M277dw_xx_,
where xx is a unique ID taken from its MAC address. It appears in
/etc/cups/printers.conf, flagged as having come from cups-browsed.
Printing is successful.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.

With both: both of the printers mentioned above appear in the GTK dialog
and in /etc/cups/printers.conf. Both print successfully.

GTK with merge request 9 (Daniel's minimal backport)


| cups-browsed installed  |
|no  | yes|
|||
printer manually configured   no| unavailable|duplicated  |
 yes| works  |dup., only one works|
|||

With no configuration and no cups-browsed: No printers are listed

With cups-browsed only: One printer, HP_Color_LaserJet_MFP_M277dw_xx_,
where xx is a unique ID taken from its MAC address. Printing is successful.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.

With both: both of the printers mentioned above appear in the GTK dialog
and in /etc/cups/printers.conf. Only the first one printed successfully:
the second logged "NO_DEST_FOUND".

GTK with merge request 6 (full backport from 3.24.29)
=

| cups-browsed installed |
|no  | yes   |
||---|
printer manually configured   no| works  |duplicated |
 yes| works  |duplicated |
||---|

With no configuration and no cups-browsed: One printer appears in the
GTK dialog, HP_Color_LaserJet_MFP_M277dw_xx. Printing is successful.

With cups-browsed only: Two printers appear, labelled
HP_Color_LaserJet_MFP_M277dw_xx and HP_Color_LaserJet_MFP_M277dw_xx_.
Only the second one appears in /etc/cups/printers.conf, labelled as having
come from cups-browsed. Both print successfully.

With manual configuration only: One printer, HP-Color-LaserJet-MFP-M277dw.
It appears in /etc/cups/printers.conf. Printing is successful.

With both: Two printers appear, labelled HP-Color-LaserJet-MFP-M277dw
and HP_Color_LaserJet_MFP_M277dw_xx_. Both are in /etc/cups/printers.conf,
with the second one labelled as having come from cups-browsed. Both print
successfully.

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 XX)
* 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

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

[Daniel Gröber]

Hi Zack,

I was seeing the exact same problem and I posted a patch fixing the issue:
https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/9

Could you test it to see if it fixes the problem for you too?

--Daniel

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

[Zack Weinberg]

Package: libgtk-3-0
Version: 3.24.24-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: za...@panix.com

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.

According to https://github.com/apple/cups/issues/5017 it is probably
the print dialog box’s responsibility to determine that a single
queue has been reported twice (e.g. by cupsEnumDests()) and merge the
information from both reports.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgtk-3-0:amd64 depends on:
ii  adwaita-icon-theme   3.38.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-9
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-3
ii  libepoxy01.5.5-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.7-1
ii  libgtk-3-common  3.24.24-1
ii  libharfbuzz0b2.7.4-1
ii  libjson-glib-1.0-0   1.6.0-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  librest-0.7-00.8.1-1.1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-egl1  1.18.0-2~exp1.1
ii  libx11-6 2:1.7.0-2
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon01.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 2.0-1

Versions of packages libgtk-3-0:amd64 recommends:
ii  libgtk-3-bin  3.24.24-1

Versions of packages libgtk-3-0:amd64 suggests:
ii  gvfs 1.46.2-1
ii  librsvg2-common  2.50.3+dfsg-1

-- no debconf information