I hoped the paragraph called 'This breakage happens if both conditions below are met:' would have done the trick.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'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.
I tried to create a Common Issues entry for our users here:
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.
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.
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.
Now, I have a load of questions:
Almost - the difference is the problem can happen even if you install the driverless USB device with classic driver on clean Fedora.1. Is Chris' summary above correct?
Only USB printers which are capable of using IPP-over-USB. See the quick docs how to find out.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?
I'm sorry, idk - but usually every new USB
printer/scanner/multifunction device made around 2014 and newer
has this support.
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.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?
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.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)?
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.
Driver removal is not needed - removal of permanent print queue (printer) suffices for make printing and scanning work.8. Is it necessary that Joe also removes the real driver from the system (like hplip), or will the action described above be sufficient?
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)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).
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.
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.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.
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
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
