Fwd: regression in printing and scanning, when upgrading to f36

test-owner@xxxxxxxxxxxxxxxxxxxxxxx · Wed, 30 Mar 2022 08:55:00 +0000

    Forwarding the message, I wasn't a subscriber before.

      -------- Forwarded Message --------

            Subject:

            Re: regression in printing and scanning, when upgrading
              to f36

            Date: 
            Wed, 30 Mar 2022 08:55:00 +0000

            From: 
            test-owner@xxxxxxxxxxxxxxxxxxxxxxx

            To: 
            zdohnal@xxxxxxxxxx

      Your message to the test mailing-list was rejected for the
      following

      reasons:

      The message is not from a list member

      The original message as received by Mailman is attached.

--- Begin Message ---

Subject: Re: regression in printing and scanning, when upgrading to f36
From: Zdenek Dohnal <zdohnal@xxxxxxxxxx>
Date: Wed, 30 Mar 2022 10:54:52 +0200
In-reply-to: <CAJCQCtRJqgkK2M5Y-bzoCDmPktjNoFGa8ioe1JD-faSdaMfS+Q@mail.gmail.com>
References: <CAJCQCtRJqgkK2M5Y-bzoCDmPktjNoFGa8ioe1JD-faSdaMfS+Q@mail.gmail.com>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

Hi all,

On 3/29/22 23:25, Chris Murphy wrote:
Hi testers,

At the Workstation working group meeting, today we learned about the
following bugs:

Cannot print except when rebooting computer after upgrade from F35 ->
after recommended manual intervention, now cannot print except after
turning off printer and then printing a blank page in LibreOffice
https://bugzilla.redhat.com/show_bug.cgi?id=2066528

Cannot scan anything with Simple Scan after upgrading F35 -> F36
https://bugzilla.redhat.com/show_bug.cgi?id=2069277

Background reading is here:
https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/BISRSRAUSMMKK34UBAGP44QL7MPZ74GI/

The very rudimentary summary is:
1. When upgrading (does not apply to clean installs);
2. with a printer that supports ipp-usb (a.k.a. driverless printing);
3. using the native driver (which can be a cups filter, free or nonfree)
Printing breaks.

The reason is the printing subsystem is going to try to use ipp-usb
(driverless) printing but things get confused in an apparently
unavoidable way. The user will have to delete the printer and readd it
manually.

Workstation users are not expected to readd USB printers in case the 
devices are capable of supporting IPP-over-USB standard - modern print 
dialogs (GTK, libreoffice) support temporary queues, which appear just 
for the print dialog itself and disappear after some time.

No manual installation is required for IPP-over-USB devices. Of course 
there can be buggy devices and corner cases which aren't currently 
covered by the default setup, but IIRC final release criteria for 
printing is the printing works at least on one device available to 
testers and PDF can be printed via it.

I've tested ipp-usb on our lab's Canon MF 440 printer which supports 
IPP-over-USB and I was able to print from evince, libreoffice and via 
CLI lp tool.

Does this violate any release criterion? About the best I've come up
with is the default panel functionality criterion. Workstation working
group thinks if it's not a blocker per the normal process of
determining blockers, then we should ask FESCo to make it a blocker.

While what to do about it isn't directly related to blockeryiness,
some of the options floated:

* punt the change to F37 (I'm not sure it's possible at this point, cc'd Zdenek)
Well I can remove the recommendation from CUPS in F36, but upgrades from 
F35 will still be affected. But anyone with fresh install will be 
without ipp-usb, although fresh installs don't have any installed broken 
queues, so removing recommendation won't help for migration at all.
* have a notification pop-up warn the user (this is probably an f37 timeframe)

Interesting idea - where would you propose to show the one-time 
notification? How would you propose to implement it to be not-disturbing 
for users which don't have the IPP-over-USB device - you can most 
reliably tell the device is IPP-over-USB  only by querying its USB 
interfaces, which works only when the device is up.

The viable way would be %post scriptlet in spec file, but that doesn't 
work on immutable systems as Silverblue.

* have a one time service delete all the printers, thereby forcing the
user to readd them, and then document this story

The statements from above still stand, with addition to removing all USB 
queues indiscriminately, which will cause another set of reported issues...

I can think about a RPM trigger which can remove USB queues 
indiscriminately when ipp-usb is installed, but if I compare the groups 
of users affected by this indiscriminate removal and group of users 
which have IPP-over-USB devices, the indiscriminate removal will hit 
(and possibly generate more bugzillas) more users than ipp-usb hits now 
- so IMHO it is not valuable to implement.

Zdenek

Thanks,

--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC

--- End Message ---
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

Subject:	Re: regression in printing and scanning, when upgrading to f36
Date:	Wed, 30 Mar 2022 08:55:00 +0000
From:	test-owner@xxxxxxxxxxxxxxxxxxxxxxx
To:	zdohnal@xxxxxxxxxx