017 included the usbreset utility which is gone after upgrading to 018. Upstream changelog [1] doesn't mention removal, only "Add a manpage for usbreset" [1] https://lwn.net/Articles/995109/ Reproducible: Always
see following copied from meson.build: > # By default, usbreset does not get installed as it could cause problems, it's > # in the repo for those that wish to try it out. > executable('usbreset', usbreset_sources, install: false) so it seems upstream consider it's still unstable. for test, one can: # ebuild sys-apps/usbutils/usbutils-018.ebuild clean install executable is here: /var/tmp/portage/sys-apps/usbutils-018/work/usbutils-018-build/usbreset
maybe wen can decide whether to install or not by a user controlled USE flag (disabled by default)?
As far as I understand, it was stable before and will become stable again eventually? Besides, a USE flag would be awesome of course and certainly wouldn't hurt.
> As far as I understand, it was stable before and will become stable again > eventually? it's handled in src_install: dobin usbreset # noinst_PROGRAMS, but installed by other distros since 018, build system switch to meson, so this is missed? I'll submit a PR to include it back
awesome, thank you!
FWIW: ``` commit 0af5b4968d579ce53f5e1e2f8274c90291493f2b Author: Sam James <sam@gentoo.org> Date: Thu Nov 14 04:32:17 2024 +0000 sys-apps/usbutils: add 018 * Switch to Meson * Drop usbreset I've not kept usbreset as in meson.build, it's marked as: """ By default, usbreset does not get installed as it could cause problems, it's in the repo for those that wish to try it out. """ If someone wants it, please file a bug to let us know. * Fix LICENSE to be GPL-2+ Signed-off-by: Sam James <sam@gentoo.org> ```
> If someone wants it, please file a bug to let us know. ah, i missed this. I also recall I've a use case which need 'usbreset' to work. It's a usb wireless NIC, after first insert, it'll show as a USB storage (which has driver for windows system), only after reset, it'll show up as NIC. So let's included it back, :)
For me it's the prime solution for buggy/crashing firmware. Regular health checks + usbreset makes those bad dongles & devices usable. I wouldn't mind setting a USE flag that is off by default.
> I also recall I've a use case which need 'usbreset' to work. It's a usb > wireless NIC, after first insert, it'll show as a USB storage (which has > driver for windows system), only after reset, it'll show up as NIC. I remembered it wrongly, the command I used is usb_modeswitch, so I don't know is it safe to include usbreset back w/o controlled by USE? If a USE is required, please suggest one?
I just asked upstream [1] and it seems it could potentially damage hardware. (I can't see that, since usbreset is basically just a helping wrapper around USBDEVFS_RESET ioctl, but what do I know.) Personally, I'm using it for years (since the advent of cheap USB SDRs which can be used 24/7 by resetting them reqularly) without any problems [2]. But I could use my own ebuild, since there are multiple versions of usbreset.c floating around. To avoid potential bugreports about burning hardware, it might be favorable to not include it and have users manually compile it. Otherwise i'd suggest "usbreset - additionally compile the potentially problematic usbreset util" as USE flag, since it's self explaining without description and shouldn't collide with other USE flags. [1] https://github.com/gregkh/usbutils/issues/214 [2] https://www.rtl-sdr.com/fixing-usb-reset-problems-for-247-rtl_433-monitoring/
PR updated, 'usbreset' will be built only with both USE="usbreset" and environment variable "I_ALLOW_TO_BREAK_MY_HARDWARE=yes".
