libusb 0.1 has been superseded by libusb 1.0, which as a new API in
order to fix design deficiencies with USB 2.0 and 3.0 in mind. It is
not supported upstream anymore and should be considered deprecated. We
should avoid shipping it with stretch if possible.

Hi,

Maybe we should switch from libusb0.1 to libusb-compat-0.1 before
dropping it completly (which may take some time, since the changed
API must be supported upstream).

http://www.libusb.org/wiki/libusb-compat-0.1

Hi,

Yes, there is even bug #731424 opened for it. I personally don't really
see the point of changing one library for another, except maybe
introducing some bugs in the switch. I remember there were some issues
with this compat library, but they might have been fixed in the
meantime. Also it hasn't seen any change in the last 3 years, and not
much development besides bug fixes in the last 6 years.

Aurelien

Aurelien Jarno wrote...

Hello,

future maintainer of one of the affected packages (u3-tool) here.
To ease migration, are there documents around that describe the
changes required for the transition, or at least code that was changed
accordingly so other people can learn from? That would ease any
discussion with upstream.

    Christoph

Hi,

OpenOCD can use libusb-compat instead. That said, I do not think I've
seen any reports from users who still need those 3 old drivers anyway.

Hi,

openocd/0.10.0-1 gained a new dependency on libusb-dev (libusb 0.1);
but the latter is destined for removal from the archive.

Regards,

I am not sure it's a good idea to switch to libusb-compat, it's just
switching from a dead library to a half-dead library, with the risks of
introducing new bugs.

Anyway there is still many blockers left until the libusb-0.1 removal,
so while it's still a long term goal to get it removed, it probably
won't be achievable for buster.

We believe that the bug you reported is fixed in the latest version of
libticables, 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 810470@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas B. Mundt <andi@debian.org> (supplier of updated libticables 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: Sat, 19 May 2018 08:55:43 +0300
Source: libticables
Binary: libticables-dev libticables2-7
Architecture: source amd64
Version: 1.3.5+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Andreas B. Mundt <andi@debian.org>
Description:
 libticables-dev - Texas Instruments link cables library [development files]
 libticables2-7 - Texas Instruments link cables library
Closes: 810470
Changes:
 libticables (1.3.5+dfsg-1) unstable; urgency=medium
 .
   * New upstream version 1.3.5+dfsg
   * Remove patches, already applied upstream.
   * Update Vcs-* links to 'salsa.debian.org'.
   * Bump Standards-Version to 4.1.4 (no changes needed).
   * Bump compatibility level to 11, remove -dbg package entry.
   * Update dependencies and 'rules'.
   * Bump SONAME and update symbols file.
   * DEP-5 copyright and update 'debian/watch'.
   * Switch to libusb 1.0 (closes: #810470).
Checksums-Sha1:
 3abe363088704917890023ad1f464a9549193a7d 2127 libticables_1.3.5+dfsg-1.dsc
 60cf453f1c331383e1649a5167e3b6b08b6e8bac 176531 libticables_1.3.5+dfsg.orig.tar.bz2
 ceee5f77797d5ab552dca7cc54841c72e9cc232e 5564 libticables_1.3.5+dfsg-1.debian.tar.xz
 9c6748216fcc33fc3f11cf90ad3483a523340397 43392 libticables-dev_1.3.5+dfsg-1_amd64.deb
 a5177ac277780c59fa6a139803147b27d0851316 102788 libticables2-7-dbgsym_1.3.5+dfsg-1_amd64.deb
 ab4ea5df141b29ff8f9b239cd62c1af398fb7156 58976 libticables2-7_1.3.5+dfsg-1_amd64.deb
 56bac0b83ca0f3e2a11467bd9b2af3f1446145e8 6891 libticables_1.3.5+dfsg-1_amd64.buildinfo
Checksums-Sha256:
 f3b144c6f61cee7039a27365ca522c7dd1ab866b185ada5049f9b3b6e97f7e0c 2127 libticables_1.3.5+dfsg-1.dsc
 cc5632a39fa0b185683c71f6f550721fda986c18cd2a24e3747ac545b82e8428 176531 libticables_1.3.5+dfsg.orig.tar.bz2
 f8939fa263750f1d1a31c18952c0f43b78c6423dfca52ac0588aebcc43e3ce07 5564 libticables_1.3.5+dfsg-1.debian.tar.xz
 baba1d951b8900e8e0677661da9ea7240f483ae8b6378934593e3340c8c2ac40 43392 libticables-dev_1.3.5+dfsg-1_amd64.deb
 0241063b381995e62bc8a65983ccbcd298ec62fcaa0ff54b0e6486f09326aaad 102788 libticables2-7-dbgsym_1.3.5+dfsg-1_amd64.deb
 9717987cba3e693d1ee6476aedfc9e79de73123e07bd85ab7cb88746bc05eac6 58976 libticables2-7_1.3.5+dfsg-1_amd64.deb
 c2e46c1cffa0cfc2b29ab37d35ee19b37afc9ab5e66efff3ec85f9c11cf165c0 6891 libticables_1.3.5+dfsg-1_amd64.buildinfo
Files:
 1c0dd33cf6f71823cf400fdc1d2cded9 2127 libs optional libticables_1.3.5+dfsg-1.dsc
 4ec2a8ce66376eb451601fbc66ce6bba 176531 libs optional libticables_1.3.5+dfsg.orig.tar.bz2
 91ab7ab5e22ac9464b0d41ddc4c87c4d 5564 libs optional libticables_1.3.5+dfsg-1.debian.tar.xz
 06335f58cad0ffa98bf080ab36e1980a 43392 libdevel optional libticables-dev_1.3.5+dfsg-1_amd64.deb
 5798b3dc68caa1af2468e7ec1ec20943 102788 debug optional libticables2-7-dbgsym_1.3.5+dfsg-1_amd64.deb
 9c04f95df3dd2818eeeea6bfb1457f3d 58976 libs optional libticables2-7_1.3.5+dfsg-1_amd64.deb
 4d0312cf221b3b58857ce7135d1e22bd 6891 libs optional libticables_1.3.5+dfsg-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEk4pc7h4pDeJV2ayYsB/qhGF7WG0FAlr/yYsACgkQsB/qhGF7
WG0TbxAAmd0/jRhn3H+yqm3e+IfrjQ1hXsRQxrAUk+HEgcKfTnh6i70vKjd/fmxu
K5JGiU6+3dF/w6wrKIhLL1HLGXqSsw4or/d+mAvhHap+C8T0TVZzcNJctDUwepsN
eROm0GgpCZESP+Vf1/vxQ77w8478nKpJtB8xWLe+MOE82G+nroKPMVw7GuRDFbdh
CZVVV5fatFawluEMvRWEeHMzEatgYJUIuI2F4AliTjAKM3tArEKOxVhYSg40311f
19DbN5oIDDTp+WVrXbbuVVtPlKKq0Ss9FLc5uPit+rul16xmv/nKahWGYFZ7f7DA
N4cPi/QdyA5SOFutrck80fa5iGFczUgE6UJJbQrTT3Nx3KtHl8idV3Djskd9xC1M
lMjAKMTSB1KRy+LwEWW2jgNfC2zgWq8+g25IADQsebZCk4ubSv4K2Tkr9CPg+G8F
drtrocFsreyfEGXSKdCaWH9TQN5UMMURTGRc9/zYOoqUhEg2Ukg6eq3ySIWms+96
mMbKorXCxISki8lKJhGIBh2Bxm9FFv5o3hINie4E8PMwM5GddY+35nf7n59jw6dl
0Iv2XCUxSHBaC6Fw6F3NEEJpXorEDkvas3piSDCeEg4P2L4Z2R7u6axbzhmNAULD
ld9sZJCIzq+JY83MIzsjRR1ZB+1FMuOFirYMl3kJJU2FRRHt/TQ=
=No0C
-----END PGP SIGNATURE-----

Sorry, I guess they should have been filed at a higher severity or
bumped at some point. But these bugs were also filed a decade ago.
libusb-1.0 1.0 has been in Unstable since 2008. The old libusb 0.1
series has been unmaintained upstream for a very long time. Early in
the forky development cycle seems a good time to raise the severity.
Packages have more than a year before the expected freezes begin for
Debian 14.

I'm trying to get the old libusb out of Testing. It's much more
difficult to complete the removal from Unstable.

Thank you,
Jeremy Bícha

Hi,

u3-tool build-depends on libusb-dev, but actually only use it on !linux
(unless you force --enable-libusb). And it FTBFS on hurd, so maybe the
best is to just drop the build-depends.

Not sure that exists. One option could be to look at a package like
avrdude (just because i looked at it not a few hours ago) which has
support for both libraries.

Regards
Aurelien

Hi,

Do you plan to fill bugs for the packages still using libusb 0.1, but
without corresponding bug? For instance lirc switch to libusb-1.0
(#810445), but later re-enabled it in version 0.10.2-0.3...

Regards
Aurelien

Can we please keep libusb0.1 for packages where it not feasible to port hem to the libusb1.0 - especially as there is zero information how to do it?(I'm seriously considering embedding libusb0.1 otherwise into avarice)

Thanks.

Hi,
severity to serious.

Regards
Aurelien

Hi Aurelien,

thanks.
However, you are the maintainer of the package and therefore in
authority of bug severities. If you don't back up Jemery's decission or
don't know why it happens it is well within your rights to dispute that
and e.g lower the severity again.

Hello,

I was also affected by this change in libusb-0.1 (through avrdude and
AVR ISP mkII).

I opened a bug upstream here
https://github.com/avrdudes/avrdude/issues/2076 where they lay out
their point of view.
Essentially migrating to libusb-1.0 is a lot of effort and considering
that they lack the manpower I understand their view completely.

On the other hand I also understand the overhead of maintaining
abandoned libraries in Debian but considering that the dependent
projects may not be able to support the effort to port to libusb1.0.
To me it looks like we should weigh the effort of porting all these
packages to libusb1.0 or retain an old library or move to
libusb-compat. libusb-compat may be an easier pill to swallow for
upstream developers.

I could help with packaging libusb-compat since I have experience with
debian packaging but I do not have experience with Debian itself.

Regards,
Stefanos