On 4/1/22 11:21, Alexander Pevzner wrote:
Hi Zdenek,
is there any way for me to read this discussion from the very beginning?
Hi Alex,
thanks for looking into this! This will be little difficult:
Here is the initial message:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/YL3XCMM7O27MEG6B2K54L2YSP2OJ7ZJ4/
Then my answer is attached here with email (I wasn't subscribed at the
list when I sent the answer and forwarded message is useless in web UI...)
And then thread continues here:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/4DCLLY2DG6UE7ELTNG6ZBJ5TXS3O72NU/
The core of the issue: I set a weak dependency in CUPS on ipp-usb to get
USB driverless support into Fedora by default and many users started to
hit the expected issue with ipp-usb claiming the USB port of driverless
device, which causes breakage for old driver print queue, which you can
find out only by printing or scanning.
Adam brought up an idea whether this expected issue can solved - AFAIU
it would need to redesign ipp-usb in a way that HTTP reverse proxy
created by ipp-usb would claim the USB port only when discovery or other
communication happen, and then release the port, so older ways could
claim the interface, but you will know better than me.
In the end, I removed the dependency on ipp-usb for now, until this
issue or migration is solved.
On 4/1/22 11:00, Zdenek Dohnal wrote:
On 3/31/22 17:59, Adam Williamson wrote:
Yeah fair point. I think the ick factor is the main reason why I'm
thinking something really needs to be done to make it better. But
unfortunately I'm not really thinking of a great way to handle this
other than Common Bugs. Maybe with Common Bugs now being migrated to
Ask Fedora, they'll get more visibility. And I can also try to
remember to give #fedora folks a heads up about it on IRC/matrix.
Yeah, my problem broadly with taking this bug as a blocker is "nobody
seems to have a great idea what we would then do to resolve it".
Is the underlying problem - that apparently existing "legacy"
configuration and IPP-over-USB cannot peacefully coexist - really
unsolvable? Fixing that seems like the *best* thing we could do...
I've added Alex, the upstream author, into CC of this email, to give
us further knowledge. The same situation happened in Debian and
Ubuntu and it ended as a common bug as well.
AFAIK ipp-usb creates HTTP reverse proxy over the USB port and keeps
it for further communication - fixing this would probably mean to
release the port, but keep the proxy the running and claim the USB
once there is a request - but I'm not sure whether it is worth of
effort to redesign ipp-usb for drivers, which are deprecated for
twelve years and they will go away in year or two.
@Chris, I've removed the weak dependency on ipp-usb in cups[1] and
sane-airscan[2], can you/I remove
https://bugzilla.redhat.com/show_bug.cgi?id=2066528 from final
blocker proposals now?
Zdenek
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f4925bd0a
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2022-5eac55ee86
--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
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/de...@lists.fedoraproject.org/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,
_______________________________________________
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
