[IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed

[Zdenek Dohnal]

Hi all,

driverless+printer applications world of printing and scanning is coming 
in the future:

- printer driver, raw queues and other removals are planned with CUPS 
3.0, roughly in the next year,
- printer applications RPMs are waiting for cups-filters 2.0, but the 
apps are in SNAP already for people to try them,
- driverless scanning is already possible with sane-airscan, which 
supports WSD and eSCL protocols.

and since ipp-usb is in Fedora for a while (since Fedora 32), CUPS and 
sane-airscan packages started to recommend ipp-usb package, which 
unfortunately leads to expected breakage (see known issues[1] - either 
under HPLIP or golang-github-openprinting-ipp-usb) due a conflict on USB 
port.

_This breakage happens if both conditions below are met:_

- the device supports IPP-over-USB - how to find out here[2]
- the device is currently installed with a classic driver, (f.e. HPLIP - 
has its device uri starting with 'hp:/usb/'),

_The __behavior__of breakage_ is:

- for printing - the old queue is available, but when a job is sent it 
prints nothing, with errors in the logs as:

hp[3559]: io/hpmud/musb.c 515: invalid claim_interface 7/1/4: Device or resource busy

- for scanning - the scanner is not recognized by the classic driver, 
but sane-airscan should kick in and provide functional device, so a new 
device should appear in scanning dialog


_The breakage is __expected__for IPP-over-USB devices_, because ipp-usb 
is running on the USB port, prepared for incoming IPP requests. This 
behavior blocks the port for other binaries, which can try to access it, 
such as printing and scanning backends (pixma, hp, hpaio...).

Unfortunately there is no clean upgrade path to solve the migration 
automatically because of unrealistic requirements such as:

- the USB device would have needed to be plugged in and turned on during 
the update
- %post scriptlets don't work the same way on immutable Fedoras as on 
Fedora Linux, and other upgrade possibilities such as Leapp don't 
support Fedora upgrades AFAIK,

the fix has to be done manually.


_How to fix the breakage:_

- printing - remove the old print queue and start using CUPS temporary 
queue[3], which is supported by modern print dialogs, or install the new 
queue permanently by:

$ lpadmin -p <queue_name> -v ipp://localhost:60000/ipp/print -m 
everywhere -E

ipp-usb advertises the printer only to localhost at port 60000 by 
default, any other USB printer capable of IPP-over-USB will be available 
at port 60001 etc...

- scanning - sane-airscan should automatically pick the device up, if 
the device supports eSCL or WSD protocols - here [4] is the growing list 
of devices, which were identified by users as they are working with 
sane-airscan.

In case you have only one device supported by the driver package and the 
driver is a list package, you can safely remove the driver package


_If the driverless setup with ipp-usb doesn't work for you:_

It would be great if you filed a bug at https://bugzilla.redhat.com for 
golang-github-openprinting-ipp-usb component after you've gone through 
the useful tricks for printing[8], 'How to fix the breakage' from this 
email and known issues of CUPS[9].

If the device is unusable for ipp-usb due a serious firmware bug, we can 
add a quirk upstream rejecting this device in ipp-usb, so the daemon 
will ignore the device and the quirk will be shared with all users - so 
the device can be again used with classic driver or with, in the future, 
with a printer application.

If user wants to go with classic drivers again, 
golang-github-openprinting-ipp-usb-0.9.20 (currently in rawhide and for 
other releases in testing repo - F36[5], F35[6], F34[7]) supports device 
quirks in /etc/ipp-usb/quirks directory. See 'man ipp-usb' for more info.
__


_Affected OS versions:_

Fedora 36+ and users who installed cups-2.3.3op2-15.fc35/fc34 updates - 
the change was reverted in cups-2.3.3op2-16.fc35/fc34, but ipp-usb is 
not removed with the new CUPS update, so it has to be removed manually 
or the setup has to be migrated ('How to fix the breakage') to ipp-usb.


_SUMMARY:_

I'm deeply sorry for the inconvenience during the breakage and for not 
announcing the change in advance via proper channels - hopefully 
driverless setup with ipp-usb can help you with using the device without 
additional drivers, proprietary binary blobs and its 'installation' (in 
case of CUPS temporary queues you don't need to install the printer at 
all, that's why installation with quotes) will be more smoother.


Thank you for your time and effort!


Zdenek


[1] 
https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_golan...

[2] 
https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_...

[3] 
https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/#_tempor...

[4] https://github.com/alexpevzner/sane-airscan#compatibility

[5] https://bodhi.fedoraproject.org/updates/FEDORA-2022-037458e247

[6] https://bodhi.fedoraproject.org/updates/FEDORA-2022-140993eb13

[7] https://bodhi.fedoraproject.org/updates/FEDORA-2022-f151accd9b

[8] https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks

[9] https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_cups

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

[Michael Catanzaro]

(removing [e-mail])...

On Wed, Mar 23 2022 at 01:58:33 PM +0100, Zdenek Dohnal 
<zdohnal(a)redhat.com&gt; wrote:
>  Unfortunately there is no clean upgrade path to solve the migration 
>  automatically because of unrealistic requirements such as:
>  
>   - the USB device would have needed to be plugged in and turned on 
>  during the update
>   - %post scriptlets don't work the same way on immutable Fedoras as 
>  on Fedora Linux, and other upgrade possibilities such as Leapp don't 
>  support Fedora upgrades AFAIK,
>  the fix has to be done manually.
>   
Hi Zdenek,

First, thanks for your work on preparing Fedora for CUPS 3.0 and 
driverless printing, and for helping me with the printer and scanner 
bug reports I reported after I discovered this broke my printer after 
upgrading to F36:

https://bugzilla.redhat.com/show_bug.cgi?id=2066528
https://bugzilla.redhat.com/show_bug.cgi?id=2069277

Hopefully my experience after removing my old print queue and switching 
to the CUPS temporary queue is an anomaly. I know we don't *expect* 
users to have this much trouble. That said, even if everything goes as 
expected, requiring users to remove the original broken print queue is 
unfortunate. Leaving a broken scanner device around is too.

I understand it is difficult to seamlessly upgrade users from F35 -> 
F36 due to the intrusive nature of these changes. That said, I think 
it's worth discussing whether a smoother upgrade is possible, because 
otherwise I expect a large number of complaints from users. An 
installed one-shot systemd service would avoid the need for any %post 
scriplets, for example. Alternatively, could we find a way to disable 
the classic drivers if the printer supports ipp-usb?

>  - the USB device would have needed to be plugged in and turned on 
during the update

I understand the problem is you don't know whether the printer supports 
ipp-usb unless it's on, right? Therefore, a one-time upgrade script has 
no way to know whether the print queue should be deleted or not?

Perhaps it would be possible to delete the print queue that uses the 
traditional driver whenever support for ipp-usb is detected? I don't 
know enough about printing to say whether that is a reasonable 
suggestion or a ridiculous one. Just brainstorming.

Michael

[Zdenek Dohnal]

On 3/30/22 03:26, Michael Catanzaro wrote:
>  (removing [e-mail])...
>
>  On Wed, Mar 23 2022 at 01:58:33 PM +0100, Zdenek Dohnal 
>  <zdohnal(a)redhat.com&gt; wrote:
> > Unfortunately there is no clean upgrade path to solve the migration 
> > automatically because of unrealistic requirements such as:
> >
> >  - the USB device would have needed to be plugged in and turned on 
> > during the update
> >  - %post scriptlets don't work the same way on immutable Fedoras as 
> > on Fedora Linux, and other upgrade possibilities such as Leapp don't 
> > support Fedora upgrades AFAIK,
> > the fix has to be done manually.
> >
>  Hi Zdenek,
>
>  First, thanks for your work on preparing Fedora for CUPS 3.0 and 
>  driverless printing, and for helping me with the printer and scanner 
>  bug reports I reported after I discovered this broke my printer after 
>  upgrading to F36:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=2066528
>  https://bugzilla.redhat.com/show_bug.cgi?id=2069277
>
>  Hopefully my experience after removing my old print queue and 
>  switching to the CUPS temporary queue is an anomaly. I know we don't 
>  *expect* users to have this much trouble. That said, even if 
>  everything goes as expected, requiring users to remove the original 
>  broken print queue is unfortunate. Leaving a broken scanner device 
>  around is too.
>
>  I understand it is difficult to seamlessly upgrade users from F35 -> 
>  F36 due to the intrusive nature of these changes. That said, I think 
>  it's worth discussing whether a smoother upgrade is possible, because 
>  otherwise I expect a large number of complaints from users. An 
>  installed one-shot systemd service would avoid the need for any %post 
>  scriplets, for example. 
That could help us on immutable systems - but I'm not sure when the 
service should run - I would expect it would run once a certain CUPS 
version is on the system, but I'm not sure how to make it run only once 
when it is installed without any %post/%triggerin in RPM. And what 
should trigger the run of the service?

Maybe an idea? The service will be brought up by udev rule - if action 
'ADD' happens during restart as well, the daemon should be loaded during 
machine restart and when the printer is turned on - it will be run only 
for IPP-over-USB device, construct the URI for the device and then try 
to find the URI among local permanent queues. WDYT? Does the action 
'ADD' is

>  Alternatively, could we find a way to disable the classic drivers if
>
>  the printer supports ipp-usb? 
Hmm... what I can think of we could come up with deny lists for classic 
driver projects (hplip, gutenprint, sane-backends), so users could 
define idVendor and idProduct and reject the  device in the classic 
driver. However this would fit better the scanning stack, since there is 
automatic device discovery for classic drivers.

For printers permanent queue installation with a classic driver always 
requires user intervention - IMO we should not block users which 
explicitly want to install print queue with classic driver.

>  > - the USB device would have needed to be plugged in and turned on 
>  during the update
>
>  I understand the problem is you don't know whether the printer 
>  supports ipp-usb unless it's on, right? Therefore, a one-time upgrade 
>  script has no way to know whether the print queue should be deleted or 
>  not? 
Exactly.
>  Perhaps it would be possible to delete the print queue that uses the 
>  traditional driver whenever support for ipp-usb is detected?  
Yes, that could be
possible, but it will work only if the device is 
turned on when the service is started.
>  I don't know enough about printing to say whether that is a
> reasonable 
>  suggestion or a ridiculous one. Just brainstorming. 
No problem, it helps me to think about the problem from another angle.

>  Michael
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam on the list, report it: 
>  https://pagure.io/fedora-infrastructure 
-- 
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC

[Benjamin Berg]

Hi,

On Wed, 2022-03-30 at 15:55 +0200, Zdenek Dohnal wrote:
>  On 3/30/22 03:26, Michael Catanzaro wrote:
>  > (removing [e-mail])...
>  > 
>  > On Wed, Mar 23 2022 at 01:58:33 PM +0100, Zdenek Dohnal 
>  > <zdohnal(a)redhat.com&gt; wrote:
>  > > Unfortunately there is no clean upgrade path to solve the migration 
>  > > automatically because of unrealistic requirements such as:
>  > > 
>  > >  - the USB device would have needed to be plugged in and turned on 
>  > > during the update
>  > >  - %post scriptlets don't work the same way on immutable Fedoras as 
>  > > on Fedora Linux, and other upgrade possibilities such as Leapp don't 
>  > > support Fedora upgrades AFAIK,
>  > > the fix has to be done manually.
>  > > 
>  > Hi Zdenek,
>  > 
>  > First, thanks for your work on preparing Fedora for CUPS 3.0 and 
>  > driverless printing, and for helping me with the printer and scanner 
>  > bug reports I reported after I discovered this broke my printer after 
>  > upgrading to F36:
>  > 
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2066528
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2069277
>  > 
>  > Hopefully my experience after removing my old print queue and 
>  > switching to the CUPS temporary queue is an anomaly. I know we don't 
>  > *expect* users to have this much trouble. That said, even if 
>  > everything goes as expected, requiring users to remove the original 
>  > broken print queue is unfortunate. Leaving a broken scanner device 
>  > around is too.
>  > 
>  > I understand it is difficult to seamlessly upgrade users from F35 -> 
>  > F36 due to the intrusive nature of these changes. That said, I think 
>  > it's worth discussing whether a smoother upgrade is possible, because 
>  > otherwise I expect a large number of complaints from users. An 
>  > installed one-shot systemd service would avoid the need for any %post 
>  > scriplets, for example.
>  
>  That could help us on immutable systems - but I'm not sure when the 
>  service should run - I would expect it would run once a certain CUPS 
>  version is on the system, but I'm not sure how to make it run only once 
>  when it is installed without any %post/%triggerin in RPM. And what 
>  should trigger the run of the service?
>  
>  Maybe an idea? The service will be brought up by udev rule - if action 
>  'ADD' happens during restart as well, the daemon should be loaded during 
>  machine restart and when the printer is turned on - it will be run only 
>  for IPP-over-USB device, construct the URI for the device and then try 
>  to find the URI among local permanent queues. WDYT? 
Sounds reasonable, it probably isn't too bad to do a little bit more
work here and run a migration script every time a printer supported by
ipp-usb is plugged in.

Not sure, maybe one could do that from inside ipp-usb. Or, possibly by
adding a new (template) service that is launched by systemd to the udev
rule, e.g.
  ENV{SYSTEMD_WANTS}+="ipp-usb-migrate@.service"
to the udev rule.

That way a script can be executed that receives the sysfs path of the
printer (%I argument). If that information is enough to delete the
queue from cups, then this might be a solution to the issue.

And, one can still touch a file to skip running the script the next
time the printer is discovered.

Benjamin

>  
>  > Alternatively, could we find a way to disable the classic drivers if 
>  > the printer supports ipp-usb?
>  
>  Hmm... what I can think of we could come up with deny lists for classic 
>  driver projects (hplip, gutenprint, sane-backends), so users could 
>  define idVendor and idProduct and reject the  device in the classic 
>  driver. However this would fit better the scanning stack, since there is 
>  automatic device discovery for classic drivers.
>  
>  For printers permanent queue installation with a classic driver always 
>  requires user intervention - IMO we should not block users which 
>  explicitly want to install print queue with classic driver.
>  
>  > 
>  > > - the USB device would have needed to be plugged in and turned on 
>  > during the update
>  > 
>  > I understand the problem is you don't know whether the printer 
>  > supports ipp-usb unless it's on, right? Therefore, a one-time upgrade 
>  > script has no way to know whether the print queue should be deleted or 
>  > not?
>  Exactly.
>  > 
>  > Perhaps it would be possible to delete the print queue that uses the 
>  > traditional driver whenever support for ipp-usb is detected? 
>  Yes, that could be possible, but it will work only if the device is 
>  turned on when the service is started.
>  > I don't know enough about printing to say whether that is a reasonable 
>  > suggestion or a ridiculous one. Just brainstorming.
>  
>  No problem, it helps me to think about the problem from another angle.
>  
>  > 
>  > Michael
>  > 
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > 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/[e-mail]
>  > Do not reply to spam on the list, report it: 
>  > https://pagure.io/fedora-infrastructure
>  
>  -- 
>  Zdenek Dohnal
>  Software Engineer
>  Red Hat, BRQ-TPBC
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Kamil Paral]

Hi Zdenek,
a QA person here. This sounds like it's going to be a major headache for us
(and our users), I hope I'm wrong. I initially skipped your message,
because it was too technical (seemed targeted at system admins, not regular
users) and I don't know half of the printer-related abbreviations and
terms. I guess my blissful ignorance ends :-)

I very much like how Chris summarized the problem in a more user-friendly
language in test list [1]:

>  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.
>  
I believe this is something that was missing from your announcement.

I tried to create a Common Issues entry for our users here:
https://ask.fedoraproject.org/t/common-issues/20975

Please help me finish it by directly editing or suggesting additions and
fixes in comments. That text should be readable and actionable by an
average Joe, deep technical details can be linked. This is all just
printer-related, scanners didn't fit into my brain for the moment, they'll
get a separate treatment.

This looks like a major change, I wonder why it wasn't included in F36
ChangeSet [2]. I think we should consider adding it there, even though it's
way past the deadline. It would make the change more visible/searchable and
also make the description and workarounds more accessible.

Now, I have a load of questions:
1. Is Chris' summary above correct?
2. Does this affect only USB printers, and no network printers?
3. Can you estimate what portion of our user base (who own printers) is
going to be affected by this? How common are printers supporting IPP over
USB?
4. If the printer doesn't support IPP over USB, what will happen? Will the
printer continue to work as usual, and the ipp-usb package will not
interfere?
5. How can an average Joe tell whether he's using a classic driver (which
is incompatible with ipp-usb)?
6. When you talk about 'removing the old print queue', is it the same as
removing the printer from system settings (e.g. gnome-control-center)?
7. If Joe removes the printer from system settings, what will happen then?
Is a reboot necessary? Will the printer magically appear there by some
autodiscovery? Or is it necessary to manually add the printer, but no
driver selection is needed? Alternatively, is it possible that the printer
will only appear in print dialogs (from different apps), but it will not be
listed in system settings?
8. Is it necessary that Joe also removes the real driver from the system
(like hplip), or will the action described above be sufficient?
9. I read that Firefox might not work with the new setup [3][4]. I'm *very*
concerned about that. Can you elaborate? When exactly will printing from
Firefox not work? For all IPP over USB printers handled through ipp-usb?
10. Can it happen that the IPP-over-USB approach offers less printing
options than its real driver counterpart? E.g. paper types, color
adjustments, etc. What if the user wants to use the real driver instead,
for these reasons, what is the recommended approach? (Ideally for an
average Joe, if possible, i.e. no lpadmin commands).
11. What can we do better during the upgrade? I read we can't fix this
perfectly. But even if the package removed all "print queues" during
installation, it would go from "My printer doesn't print and I have idea
why, I'm so angry" situation into "My printer disappeared, I had to add it
again, I'm so angry" situation (in case it wasn't IPP over USB, in which
case it would be autodetected and immediately re-appear). That seems like
an obvious lesser evil. In the first case, you have no idea what to do,
except for magically stumbling on our documentation. In the second case,
it's obvious that you need to add the printer again, if it is not there,
and so it allows users to fix the situation themselves pretty naturally. I
understand this won't work on rpm-ostree based systems, but it's still a
huge leap forward. Am I misunderstanding something?
12. This can still be reverted, right? It's enough to stop recommending
ipp-usb in F36, correct? Or is there a technical reason why that mustn't be
changed? I simply wonder whether we still have a way out if this is deemed
too catastrophic without some automatic workarounds like the one proposed
above.

Thanks!
Kamil

[1]
https://lists.fedoraproject.org/archives/list/[e-mail]...
[2] https://fedoraproject.org/wiki/Releases/36/ChangeSet
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2066528#c4
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1983403

[Michael Catanzaro]

On Thu, Mar 31 2022 at 02:19:35 PM +0200, Kamil Paral 
<kparal(a)redhat.com&gt; wrote:
>  10. Can it happen that the IPP-over-USB approach offers less printing
>
>  options than its real driver counterpart? E.g. paper types, color 
>  adjustments, etc. 
With hplip my printer had three color mode options: color, high-quality 
grayscale (using color), or black-only grayscale (what I normally used).

With ipp-usb, my printer has six options: color, grayscale, deep gray, 
device gray, device RGB, and deep color. I have no idea what the last 
four of these mean. I also don't know whether the grayscale setting 
corresponds to high-quality grayscale or black-only grayscale. Not sure 
how to avoid using color ink when I only need black.

So technically this is *more* printing options, but it sure feels like 
less, since I don't see the black-only option there anymore.

Michael

[Chris Murphy]

On Thu, Mar 31, 2022 at 9:10 AM Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:

>  With ipp-usb, my printer has six options: color, grayscale, deep
> gray,
>  device gray, device RGB, and deep color. I have no idea what the last
>  four of these mean. I also don't know whether the grayscale setting
>  corresponds to high-quality grayscale or black-only grayscale. Not sure
>  how to avoid using color ink when I only need black. 
My guess is to think of them this way

1. Internally uses some form of color management (could be ICC or
proprietary or combination). The "deep" version means "more of". So
that'd be more contrast and more color saturation.
color, deep color
grayscale, deep gray

2. These "pass through" the values in the printed file and do not
compensate for the device's behavior at all, so it should be fairly
"raw" output suitable for making ICC profiles. As the device doesn't
really have RGB inks, there's still some (likely proprietary) internal
RGB to CMYK conversion, or however many inks there are, e.g. CcMmYKk
(for dark and light variations of those inks).
device gray, device RGB

I expect "device gray" will get you black ink only output. It's a toss
up whether grayscale and/or deep gray actually use some color inks in
order to produce smoother results, in particular using a balance of
the light inks would produce better gradation.



>  So technically this is *more* printing options, but it sure feels
> like
>  less, since I don't see the black-only option there anymore. 
Yeah. Jargon.



-- 
Chris Murphy

[Zdenek Dohnal]

Hi Kamil,

On 3/31/22 14:19, Kamil Paral wrote:
>  I very much like how Chris summarized the problem in a more 
>  user-friendly language in test list [1]:
>
>      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.
>
>
>  I believe this is something that was missing from your announcement. 
I hoped the
paragraph called _'This breakage happens if both conditions 
below are met:' _would have done the trick.
__
>  I tried to create a Common Issues entry for our users here:
>  https://ask.fedoraproject.org/t/common-issues/20975
>
>  Please help me finish it by directly editing or suggesting additions 
>  and fixes in comments. That text should be readable and actionable by 
>  an average Joe, deep technical details can be linked. This is all just 
>  printer-related, scanners didn't fit into my brain for the moment, 
>  they'll get a separate treatment. 
I've added more details in the bug where
you added the link 
https://bugzilla.redhat.com/show_bug.cgi?id=2066528 - please let me know 
which stuff I can specify further.
>  This looks like a major change, I wonder why it wasn't included in F36 
>  ChangeSet [2]. I think we should consider adding it there, even though 
>  it's way past the deadline. It would make the change more 
>  visible/searchable and also make the description and workarounds more 
>  accessible. 
This is completely my fault, I'm deeply sorry for that - I took ipp-usb 
being in Fedora for some time, its existence was advertised several 
times in reports from printing groups here, other distros have it 
installed by default and the breakage is documented (for long time on 
wiki, now even on Fedora Quick Docs), so I thought the impact would be 
that wide for a Change.

If it helps you and others from problems, I will remove the 
recommendation and start the full process in F37 or F38.

>  Now, I have a load of questions: 
There are quick docs pages, which were migrated by
Brandon Nielsen 
(kudos!) and I keep them updated as SME - 
https://docs.fedoraproject.org/en-US/quick-docs/, tab Printing and 
scanning - it has terminology, known issues, useful tricks - it can help 
you as well.
>  1. Is Chris' summary above correct? 
Almost - the difference
is the problem can happen even if you install 
the driverless USB device with classic driver on clean Fedora.
>  2. Does this affect only USB printers, and no network printers?
Only USB printers which are capable of using IPP-over-USB. See the quick 
docs how to find out.
>  3. Can you estimate what portion of our user base (who own printers)
>
>  is going to be affected by this? How common are printers supporting 
>  IPP over USB? 
I'm sorry, idk - but usually every new USB printer/scanner/multifunction 
device made around 2014 and newer has this support.

>  4. If the printer doesn't support IPP over USB, what will happen?
> Will 
>  the printer continue to work as usual, and the ipp-usb package will 
>  not interfere? 
ipp-usb ignores devices which don't have IPP-over-USB USB
interface 
7/1/4. Printer and its print queue should work as usual.
>  5. How can an average Joe tell whether he's using a classic
> driver 
>  (which is incompatible with ipp-usb)? 
Device URI (from f.e. 'lpstat -v')
doesn't start with 'ipp://' and 
driver name doesn't contain 'driverless' or 'IPP Everywhere'. 
Unfortunately system settings show only 'localhost' for local 
connections... but CUPS Web UI shows both info at the printer detail.
>  6. When you talk about 'removing the old print queue', is it
> the same 
>  as removing the printer from system settings (e.g. gnome-control-center)? 
Yes - the printer in system settings is actually a print queue in CUPS 
or entry from mDNS. Print queue can be removed.

>  7. If Joe removes the printer from system settings, what will happen
>
>  then? Is a reboot necessary? Will the printer magically appear there 
>  by some autodiscovery? Or is it necessary to manually add the printer, 
>  but no driver selection is needed? Alternatively, is it possible that 
>  the printer will only appear in print dialogs (from different apps), 
>  but it will not be listed in system settings? 
Reboot is not necessary, dialogs capable of using temporary queues (GTK 
and Libreoffice) will pick up the queue when you open a print dialog - 
system settings will show an entry based on mDNS communication, which is 
a ghost printer now to tell users there is actually a printer you don't 
need to install one - I have reported a bug to gnome-control-center for 
better handling this, but seems stale 
https://bugzilla.redhat.com/show_bug.cgi?id=1765328 .

Manual print queue/printer installation shouldn't be needed, but in case 
it is there is a manual in the original email.

>  8. Is it necessary that Joe also removes the real driver from the 
>  system (like hplip), or will the action described above be sufficient? 
Driver
removal is not needed - removal of permanent print queue 
(printer) suffices for make printing and scanning work.
>  9. I read that Firefox might not work with the new setup [3][4].
> I'm 
>  *very* concerned about that. Can you elaborate? When exactly will 
>  printing from Firefox not work? For all IPP over USB printers handled 
>  through ipp-usb? 
The default intended ipp-usb usage will not work in the default
print 
dialog in Firefox, but it works once you switch to 'system dialog' on 
GNOME, which uses GTK. Or you can install the queue permanently via 
lpadmin (as I wrote in the initial email) or use the uri - 
ipp://localhost:60000/ipp/print - in CUPS Web UI (localhost:631 if 
cups.service is running)
>  10. Can it happen that the IPP-over-USB approach offers less printing
>
>  options than its real driver counterpart? E.g. paper types, color 
>  adjustments, etc. What if the user wants to use the real driver 
>  instead, for these reasons, what is the recommended approach? (Ideally 
>  for an average Joe, if possible, i.e. no lpadmin commands). 
Yes, it can happen the IPP-over-USB approach offers less options - it 
depends on what printer's firmware advertises in communication, and 
since classic drivers are still rooted deep in UIX, some manufacturers 
probably incline to provide a basic set of functionality via driverless 
protocols. Usually it can happen that there is only one print quality 
instead of three etc.

If you want to go back to classic driver, create a .conf file at 
/etc/ipp-usb/quirks and reject your device model - see 'man ipp-usb'.

But keep in mind classic drivers will go away in a year or two.

>  11. What can we do better during the upgrade? I read we can't fix
> this 
>  perfectly. But even if the package removed all "print queues" during 
>  installation, it would go from "My printer doesn't print and I have 
>  idea why, I'm so angry" situation into "My printer disappeared, I had 
>  to add it again, I'm so angry" situation (in case it wasn't IPP over 
>  USB, in which case it would be autodetected and immediately 
>  re-appear). That seems like an obvious lesser evil. In the first case, 
>  you have no idea what to do, except for magically stumbling on our 
>  documentation. In the second case, it's obvious that you need to add 
>  the printer again, if it is not there, and so it allows users to fix 
>  the situation themselves pretty naturally. I understand this won't 
>  work on rpm-ostree based systems, but it's still a huge leap forward. 
>  Am I misunderstanding something? 
There is an idea of oneshot binary which can run
as systemd service 
which can do the trick in the other reply from Michael. I would like to 
pursue that way.
>  12. This can still be reverted, right? It's enough to stop 
>  recommending ipp-usb in F36, correct? Or is there a technical reason 
>  why that mustn't be changed? I simply wonder whether we still have a 
>  way out if this is deemed too catastrophic without some automatic 
>  workarounds like the one proposed above. 
Yes, the change can be reverted - which I will do based on the feedback 
- I will do the proper change announcement once there is a migration for 
affected devices. Although it would be great if the manual for ipp-usb 
stayed on the Ask - the ipp-usb existence really needs to be spread out 
and Quick Docs or Wiki don't seem to cut it.

I'm deeply sorry for inconvenience and thank you for the feedback!


Zdenek

>  Thanks!
>  Kamil
>
>  [1] 
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  [2] https://fedoraproject.org/wiki/Releases/36/ChangeSet
>  [3] https://bugzilla.redhat.com/show_bug.cgi?id=2066528#c4
>  [4] https://bugzilla.redhat.com/show_bug.cgi?id=1983403
>
>
>  _______________________________________________
>  devel mailing list --devel(a)lists.fedoraproject.org
>  To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
>  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/[e-mail]...
>  Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
-- 
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC