On Wed, Mar 30, 2022 at 2:54 AM Zdenek Dohnal zdohnal@redhat.com wrote:
Hi all,
On 3/29/22 23:25, Chris Murphy wrote:
- 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.
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.
On 3/31/22 03:24, Chris Murphy wrote:
On Wed, Mar 30, 2022 at 2:54 AM Zdenek Dohnal zdohnal@redhat.com wrote:
Hi all,
On 3/29/22 23:25, Chris Murphy wrote:
- 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.
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.
If you recall the email I've sent to devel list about the issue, then I've sent the same email to users list as well. It could give some heads up for the users as well.
On Wed, 2022-03-30 at 19:24 -0600, Chris Murphy wrote:
On Wed, Mar 30, 2022 at 2:54 AM Zdenek Dohnal zdohnal@redhat.com wrote:
Hi all,
On 3/29/22 23:25, Chris Murphy wrote:
- 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.
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...
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
On Fri, Apr 1, 2022 at 10:00 AM Zdenek Dohnal zdohnal@redhat.com wrote:
@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?
We should probably remove the blocker proposal only once the updates hit stable. But I'll update the vote ticket [3] to indicate that Zdenek reverted this feature for F36, at least for the moment.