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/t...@lists.fedoraproject.org/thread/YL3XCMM7O27MEG6B2K54L2YSP2OJ7ZJ4/
[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@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@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/devel@lists.fedoraproject.org
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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
