Dear Maintainer, 0xffff has a build-depends on libusb-dev. A few years ago upstream has released a new major version libusb 1.0 with a different API which aims to fix design deficiencies with USB 2.0 and 3.0 in mind. The old libusb 0.1 package is not supported upstream anymore and should be considered deprecated. If 0xffff supports the new libusb 1.0 library, please consider switching the build-depends from libusb-dev to libusb-1.0-0-dev. If not please inform upstream that porting the software to the new API is recommended. Thanks, Aurelien
tag 810392 fixed-upstream thanks Hi, 0xFFFF uses libusb-1.0 instead of libusb-0.1 now: https://github.com/pali/0xFFFF/commit/d5028a12ca539638a6ae5d923e7dba0e4f30a45a
Hi Aurelien! Library libusb 1.0 is slow and unusable. Currently experimental port of 0xFFFF to libusb 1.0 (in git) is not fully functional due to slow listing/enumerating of connected usb devices. So using new libusb 1.0 is not possible to have working 0xFFFF application right now. 0xFFFF with older libusb 0.1 is working fine and does not have problem in listing usb devices. Aurelien, I would suggest to have libusb-dev (libusb 0.1) package in Debian repository, because it is stable and is working, not like new libusb-1.0-0-dev which is slow and unusable. So please consider not removing working libusb 0.1 implementation from Debian until we have other working replacement library. Thanks!
Hi, Thanks for working on porting this application. I disagree with this statement, libusb 1.0 is used in many applications without any problem. Contrary to libusb 0.1, it is a maintained library, so if you encountered any bug that makes it slow, unusable or whatever, please report a bug and a testcase, I am sure we'll find a solution. We'll keep libusb 0.1 until there are very few applications using it, but surely not eternally. Aurelien
3 days ago I sent email to libusb-devel@lists.sourceforge.net ML, now waiting for reply. So hope that this problem of slow device listing will be fixed... If you want I can CC you next. Problem is that there is just 0.3-0.5 timeout in which 0xFFFF needs to send "ping" command over usb. And running libusb 1.0 in debug mode show me that library itself was not able to detect usb device in that time window. Older libusb 0.1 does not have this problem, so this show me that new libusb 1.0 is slow and not usable for such work... Maybe other applications are not time-limited. Ok, thanks. Now you know that there is at least one application which does not work with new libusb 1.0.
I don't see your mail on the mailing list, it seems it hasn't arrived. Did you got any bounce message? Aurelien
I got "Your message to libusb-devel awaits moderator approval".
If it doesn't get accepted in the next days, please send it to me, I'll forward it there. Aurelien
I already forwarded email to you, but did not received any relevant response about this problem (slow listing of devices)...
Looks like upstream ignores this problem and so there is no other way as using working libusb 0.1 library instead that new libusb 1.0 which does not work...
Ok, upstream is definitely ignoring this problem... I got no response about it for 3 months! I really suggest to stay on libusb 0.1 library which is *working* and not forcing us to use non working slow and buggy version 1.0.
We believe that the bug you reported is fixed in the latest version of
0xffff, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 810392@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Sebastian Reichel <sre@debian.org> (supplier of updated 0xffff package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 27 Nov 2016 22:19:08 +0100
Source: 0xffff
Binary: 0xffff
Architecture: source amd64
Version: 0.6.1+git20160627-1
Distribution: unstable
Urgency: medium
Maintainer: Sebastian Reichel <sre@debian.org>
Changed-By: Sebastian Reichel <sre@debian.org>
Description:
0xffff - Open Free Fiasco Firmware Flasher
Closes: 810392 829009 843582
Changes:
0xffff (0.6.1+git20160627-1) unstable; urgency=medium
.
* New upstream snapshot
- Using libusb 1.0 (Closes: #810392)
- Partial N950 support
- Misc. fixes
* Remove BUILD_TIME patch (applied upstream)
* Install zsh completion file to correct location (Closes: #843582)
* Use new upstream URL for Homepage (Closes: #829009)
* Switch to compat level 10
* Update debian/watch to use new upstream @ github
* Update Debian Standards Version to 3.9.8
* Use secure VCS urls
Checksums-Sha1:
1edf8975e4816ff3f776fad64295c589bb3b1252 1895 0xffff_0.6.1+git20160627-1.dsc
cd6614bfd1cfbeb5c8a50958ab2e0a34bc3a6e4f 63256 0xffff_0.6.1+git20160627.orig.tar.gz
a19109863312f0a55d8d33f1fb8a4c549813c1fb 4396 0xffff_0.6.1+git20160627-1.debian.tar.xz
bc3378a9abf79fa9e7d0cb9587cdce98c865666f 125548 0xffff-dbgsym_0.6.1+git20160627-1_amd64.deb
2fa1e72c038a7693901b2005816f8fd15e4b17f7 4781 0xffff_0.6.1+git20160627-1_amd64.buildinfo
5a8bc873e1678730d28fc8de8822a1b7e58112d1 57066 0xffff_0.6.1+git20160627-1_amd64.deb
Checksums-Sha256:
470982318ade123234f9c2a2a9781aad2fac1c683056c5746579994eaf7fbe86 1895 0xffff_0.6.1+git20160627-1.dsc
dd3bc345dffb22fc5615108e910d1752dc78710759b8c032cb06f0409eab48a4 63256 0xffff_0.6.1+git20160627.orig.tar.gz
c966eb91c3e7e896f5223a8bc6eaf8c43b43b97ceda4dccb89c81e02b944fb43 4396 0xffff_0.6.1+git20160627-1.debian.tar.xz
c05ae8f091ad659295c744941603a2070c0db72b2660314164f212d10af9dd9d 125548 0xffff-dbgsym_0.6.1+git20160627-1_amd64.deb
2f4b43ce92ad6b839eff9cbab259321c82dfc3b56461cd91f3df18a71e2c1a31 4781 0xffff_0.6.1+git20160627-1_amd64.buildinfo
7595f38570a49bbae4541df638ef9f4a07a0d2b6411db3dc256523366bc13f79 57066 0xffff_0.6.1+git20160627-1_amd64.deb
Files:
881f4b6b2d0a3efd44f4d0b74066e0a8 1895 misc extra 0xffff_0.6.1+git20160627-1.dsc
2c3dba4d00673e256655a03c12a8b1d0 63256 misc extra 0xffff_0.6.1+git20160627.orig.tar.gz
7cebe53d906957d3f4d48edda3764c44 4396 misc extra 0xffff_0.6.1+git20160627-1.debian.tar.xz
5717d5b58af8e851af2ca67188a433c3 125548 debug extra 0xffff-dbgsym_0.6.1+git20160627-1_amd64.deb
8cfa2993afc719a12a184c947727c320 4781 misc extra 0xffff_0.6.1+git20160627-1_amd64.buildinfo
d3045a00df914f5eba9d7588ca8dbe01 57066 misc extra 0xffff_0.6.1+git20160627-1_amd64.deb
iQIcBAEBCAAGBQJYO1DyAAoJENju1/PIO/qax2EP/RFC+w1hYAOyZy/JY3KHIzA8
VFOhP9QLsYJxlEzqqmHyf3BA1k9IfPDuAyniJPAHE9DGb6nfAkz5+70yz5iGC8U7
P8LxuompErpurmw1jK35ZdkYtNpTwjNR22Q2KnKdkhuN63Ncm7bK+BjA89LZpHU6
ohxNiv2V3aFxhhqKuizLLlKo6wvb4szFLZMlK/1lsroOgXTjeJyxqD+cddU8xX4P
HDvxw/8Ax2TZBZGGpfcJR9Dp7z/S4HrQqSkt77FU9qnul1jnWvRxK1sT774FbbdP
YSaiD61o0/wu3mX22c9/kf4bSl4K0jfMNEjm760lWtcYr6kCUCGuD4PkE6/Bmns3
OsaVmWrjlLlPnYZF8//NyM38m+Iw3GWr8jtXwDTQgLLhi3aQlVX0dJZR9WEdsO3o
9zeGpG+0WKYPjErOdndxzX6J+YZcvr64j0uPHYkI+m4pij7UmBggwFpzx06bO0nn
y9oyk2S5fMcjkIeGQf7jyaNi66EksmYTy98uuTkHoxKhcTekt87IY9Z/szZfB7x7
MLAr+MUukJmDscHOsrQqsVaRkMYcjcT8Kk5BpRrMhOyvTGeLpOYR60UR+S/obngv
VpzDhkyxLcVvWG9N2eJwrGw/k/HT/dLMzWgrIVuXn4KyVckmDPRm/v65qJW1yMca
a20K+1vK902hQSnjmpx6
=h3ec
-----END PGP SIGNATURE-----
Bug for libusb 1.0 was reported at least two times. And after 8 months upstream libusb is totally ignoring it. It is without any (relevant) answer. So I'm reverting non-working libusb 1.0 support in my 0xFFFF project. 0xFFFF will use only libusb 0.1 library which is working -- and not libusb 1.0 anymore. Sorry, but I do not see any other option. As libusb 1.0 maintainers do not want to cooperate, I really suggest to do not remove *working* libusb 0.1 library as there is no replacement for it.
fixed 810392 0xffff/0.6.1+git20160627-1 thanks (While I have no problem keeping this bug open for discussion the version above does not use libusb 0.1, so the bug itself is fixed there) Regarding libusb1.0 bugs: For me it's exactly the other way around. I did have some problems with libusb0.1 on USB3 ports (I did not further analyse them, since it worked with the USB2 ports. On my current hardware it also worked with the USB3 ports). 0xffff linked against libusb1.0 works like a charm for me, since I cannot reproduce the bug myself I did not get involved. Maybe just report a bug on github? It looks like the issues are actively checked there: https://github.com/libusb/libusb/issues