Misc: To release 1.0.25 #777

mcuee · 2020-09-07T05:25:56Z

Merged main feature improvement

Merged main bug fixes

darwin: Don't drop partial data on timeout #876
darwin_set_interface_altsetting: Better handling if device doesn't support SET_INTERFACE #852
[regression 1.0.24] can't communicate with iPhone/iPad on Linux #825
Regression in libusb 1.0.24 under Linux -- buggy devices with configuration 0 #850
Regression in 1.0.24: libusb_handle_events_timeout_completed not waiting on timeout #858
Regression in 1.0.24: libusb 1.0.24 uses a lot of cpu in libusb_bulk_transfer under Linux #913
Regression in 1.0.24: Segfault with libusbk driver #912
Regression in 1.0.24: Filter out non-libusb I/O completions breaks Winusb HID API #863
Regression in 1.0.24: Access violation in libusb v1.0.24 when using libusbK driver #844
windows: Allow synchronous control transfer (for libusb0) #1016 (fix libusb0 regression in 1.0.24)
Fix Windows HID backend missing byte #986
Windows: Fix for data race which causes invalid current_interface in copy_transfer_data #967
Windows: Fix timeouts if only endpoint 0 exists #963
windows: Ignore any device interface GUIDs beyond the first #1010 (workaround for broken device)
Android build name correction #971
Update Android Readme #996
~~Core: Fix crash (segv) in libusb_init if backend.init failes #989~~ (unreleased regression)
~~core: Unlock and clear default ctx in all error paths in libusb_init #995~~ (unreleased regression in error path)
~~Core: Calling op_set_option even if no default context is set #942~~ (avoid regression on Android)
~~darwin: fix behavior of libusb_set_interface_alt_setting when it stal… #1031~~ (unreleased breakage on new macOS 12)

Postponed for 1.0.26 (see #1047 )

no_enumeration should be per context, not global #1003 (possible API breakage)
core: add libusb_init_context to allow setting options during context creation #1026 (solve API issue)
Windows: Deal with failed synchronous control transfers #1018 (libusb0.sys)
Darwin: Fix LIBUSB_TRANSFER_ADD_ZERO_PACKET flag #678 (postpone unless reproduced issue)
Windows: Add ability to claim multiple associated interfaces for a WINUSBX composite function #965 (very useful feature enhancement, especially for Windows users, new APIs)

mcuee · 2021-01-16T01:30:37Z

With #838 and #831 and a few other issues resolved, probably it is good to prepare for a maintainence release 1.0.25.

mcuee · 2021-01-16T01:55:32Z

I think #850 will be fixed soon as well.

mcuee · 2021-01-16T01:56:37Z

Pull request 833 should be in as well. #833

yorickvP · 2021-02-06T20:00:08Z

Hi! Great work fixing these issues! I just ran into #831 and spent a lot of time debugging until someone pointed me to the issue. It might be worth it to release 1.0.25 so nobody ends up using 1.0.24 by accident (it's the default in some distros).

mcuee · 2021-02-07T01:49:14Z

I think the following will be good to be included in the 1.0.25 release:
#833 (pending review)
#856 (reviewed, pending minor modification of commit message, this will fix #858)
#850 (pending review of #851).

tormodvolden · 2021-02-07T10:47:42Z

Please consider #847 (pending review of #852) as well, although the regression part was taken care of by #843.

mcuee · 2021-02-09T01:31:05Z

Thanks to Chris. #833 and #850 have been closed.

mcuee · 2021-02-09T01:32:12Z

@hjelmn Please help to review #852 and then see if you want to consider that for the release. Thanks.

EmptyVisual · 2021-04-14T03:36:36Z

@mcuee Can we do a partial maintenance release of the Linux regressions in #856 and #858 whilst we wait for the Darwin issues to be reviewed and merged separately? Most of us Linux users have been forcibly sitting on 1.0.23 for months now because of the bugs in the 1.0.24 release.

mcuee · 2021-04-14T03:41:00Z

I think #856 needs to be closed for the release to happen.

tormodvolden · 2021-04-14T08:06:05Z

+1 for high time to get a maintenance release with regression fixes out. I asked about #852 (Darwin) here two months ago because it is relatively trivial, but this is not a regression fix so please don't let it delay any release. Indeed it can seem like the release is hanging on #856, where the suggested fix is a massive commit with a mix of code refactoring and actual changes, API changes even. IMO it is not a critical bug fix (it was discussed whether it was a bug at all) so it could wait until after 1.0.25 and bake longer in the tree before going into a release.

mcuee · 2021-04-14T08:30:07Z

#856 fixed #858. So I think #856 is still good to be merged. Nathan already reviewed it and he mentioned just needs to change the commit message. So I think it is better to merge it before the release.

mcuee · 2021-04-14T08:30:37Z

@dickens Please weigh in as well. Thanks.

mcuee · 2021-06-01T10:33:26Z

As far as I am concerned, only #856 needs to be merged and we should be ready for an RC.

mcuee · 2021-06-05T00:49:50Z

#856 has been merged.

mcuee · 2021-06-05T05:21:27Z

BTW, if you are interested, welcome to join the maintainer team. Right now only Nathan and Chris are actively handling the release.

Release since 2015.
libusb 1.0.24: by Chris on 11 Dec 2020
libusb 1.0.23 by Nathan on on 29 Aug 2019
libusb 1.0.22 by Chris on 25 Mar 2018
libusb 1.0.21 by Nathan on 26 Oct 2016
libusb 1.0.20 by Chris on 14 Sep 2015

mcuee · 2021-06-05T05:23:25Z

The main difficulty with libusb is probably on Windows backends. As of today, there are 48 issues and half of them are related to Windows. And one of the main missing feature under Windows is Hotplug.

But never mind if you do not want to handle Windows, you can still help to handle Linux and/or macOS.

mcuee · 2021-06-06T13:29:17Z

For those who are interested to see the 1.0.25 release coming soon, please help to carry out tests on git head. Thanks.

hjelmn · 2021-06-06T14:08:36Z

I identifed why the Darwin backend is failing the stress test. Will have a fix today.

The problem is in the ordering in libusb_exit caused by destroying the cached device list when the init count goes to 0. Still not sure I agree with this behavior change. I used a library destructor function for a reason... I can fix the ordering issue but this code is somewhat more fragile than I would like.

hjelmn · 2021-06-06T15:06:47Z

Identified the issue with Linux and the stress test. Fixing.

hjelmn · 2021-06-06T15:19:01Z

Interesting question. I have always assumed this is true but we don't document it. We can call:

libusb_set_option(NULL, ...);

before the default context is created, right? If not the stress test is wrong. Otherwise I have a fix that will allow this. Will hold off of this change until I get a consensus.

hjelmn · 2021-06-06T18:23:21Z

Opened #923 as a prototype. Please comment.

mcuee · 2021-06-07T02:22:02Z

#923 seems to be good to me.

mcuee · 2021-06-07T12:08:11Z

I identifed why the Darwin backend is failing the stress test. Will have a fix today.

The problem is in the ordering in libusb_exit caused by destroying the cached device list when the init count goes to 0. Still not sure I agree with this behavior change. I used a library destructor function for a reason... I can fix the ordering issue but this code is somewhat more fragile than I would like.

Commit 676076c helps macOS stress test to have the same result as Linux and Windows. Then #923 should be able to fix the remaining segfault issues with Stress test.

But issue #924 still exists under macOS when running xusb example.

patstew · 2021-06-07T16:18:28Z

Any chance of getting #867 in? And my #312 too if there aren't any objections.

mcuee · 2021-12-03T06:33:44Z

So that the following two are pending for the RC release.

hjelmn · 2021-12-11T03:59:14Z

Yeah. I can merge #1026 but only if I can get one more review. Adding an API should be done with care and I don't want to have to replace libusb_init() more than once.

hjelmn · 2021-12-11T03:59:55Z

Once that is resolved we need to cut a new RC and get things rolling. We solved the single biggest issue blocking macOS.

mcuee · 2022-01-19T02:24:43Z

So that the following two are pending for the RC release.

no_enumeration should be per context, not global #1003

core: add libusb_init_context to allow setting options during context creation #1026

Just wondering if there are any updates on these two last remaining main issues?

tormodvolden · 2022-01-19T08:15:32Z

IMO, if they are not fixing regressions, these should wait for next release, and we should make the RC (and possibly the 1.0.25 release) with what we have in git now. I previously wanted these two items included, but as we discussed in #1026, these major API changes can need more review and no rushing. And we dearly need a 1.0.25 now.

mcuee · 2022-01-21T01:21:28Z

I agree. We can probably tag the release now, or at least the RC1.

mcuee · 2022-01-21T01:23:38Z

@hjelmn @LudovicRousseau What are your opinions?

LudovicRousseau · 2022-01-21T09:37:04Z

No objection for a release soon.

"Release early, release often". Even if we do not have the manpower for the "release often".

hjelmn · 2022-01-21T19:43:04Z

Go for it!

tormodvolden · 2022-01-21T20:28:46Z

RC1 is out, please help fill in (and extend) the test matrix in #1046. Thanks Ludovic for the autobuild stuff, that helps already build testing on a load of Windows platforms.

mcuee · 2022-01-29T02:20:15Z

@tormodvolden @hjelmn @LudovicRousseau
It seems that we are more or less ready for the 1.0.25 release. Anything else we would like to fix?

hjelmn · 2022-01-29T03:23:09Z

Looks good to me.

tormodvolden · 2022-01-29T10:55:02Z

Is there anything missing in the ChangeLog or other things worth mentioning in the release announcement?

Does anyone have the Windows binaries package *.7z build automatized or can volunteer to create it once we have the release tarball?

mcuee · 2022-01-29T11:05:16Z

Is there anything missing in the ChangeLog or other things worth mentioning in the release announcement?

Does anyone have the Windows binaries package *.7z build automatized or can volunteer to create it once we have the release tarball?

I think the changelog is okay.

As for the Windows binary, it is okay not to have that initially. I remember that was the case when we released 1.0.23. I actually do not know how the 7z Windows binary packge is created. It is not a real issue though.

Users with Visual Studio can easily build from source
vcpkg has already libusb package
MSYS2 distro will also have libusb package as well.

mcuee · 2022-01-29T11:10:29Z

The MinGW binary package is built with the following script, but you can see it is using a multilib enabled toolchain. I am not so sure what is a suitable toolchain to use in this case.
https://github.com/libusb/libusb/blob/master/.private/bm.sh

Previously the MSVC (Visual Studio) toolchain binary was built with WDK scripts (WDK 7.1.0) so it does not have the dependancies of the VC runtime packages and had the support of Windows XP. But later the WDK build scripts were removed along with remove of Windows XP support. So I am not so sure the baseline VS version for the VS binary.

tormodvolden · 2022-01-29T11:52:20Z

The 1.0.24 .7z has a long list of VS targets that correspond exactly to the Appveyor builds, so I wonder if Appveyor was used to build them, maybe locally. @LudovicRousseau's web service instance doesn't seem to store build artifacts.

mcuee · 2022-01-29T12:14:37Z

I think we can tag 1.0.25 release first so that various distributions (Linux distro, macOS Homebrew and macports, Windows vcpkg and Msys2) can take the new releases.

We can always release the official windows binary once we figured out the way. If Chris is not available, probably Pete can help as well.

LudovicRousseau · 2022-01-29T15:17:36Z

@tormodvolden I have not configured github actions to store any artifacts. That was on purpose. I don't think we need them for Unix.
It is possible to generate and store artifacts for Windows builds. But I will not take care of Windows builds myself.

Maybe the lack of Windows builds will motivate some Windows developers to help the project? :-)

tormodvolden · 2022-01-29T15:49:49Z

@LudovicRousseau I was thinking of your Appveyor builds for Windows. I think storage of artifacts can easily be enabled there, but I fully understand if you don't want to get involved in it.

I see that @dickens also has Appveyor libusb builds, also without artifacts. It is Ludovic's that currently are linked from our github page, I think it was Chris' some time ago.

LudovicRousseau · 2022-01-29T17:31:02Z

@tormodvolden I completely forgot Appveyor :-)
Everything was configured and developed by @dickens, not me.

tormodvolden · 2022-01-29T23:22:47Z

I have configured appveyor so it stores build artifacts. So I can spin a .7z with all VS builds plus MinGW cross-build, and have it uploaded before I announce the release. Tentatively on Monday night (UTC).

mcuee · 2022-01-30T01:46:52Z

I have configured appveyor so it stores build artifacts. So I can spin a .7z with all VS builds plus MinGW cross-build, and have it uploaded before I announce the release. Tentatively on Monday night (UTC).

That will be great. Thanks.

mcuee · 2022-02-01T02:29:44Z

Wonderful that we finally have the libusb 1.0.25 release.

BTW, here in Singapore it is Chinese New Year holiday today.

tormodvolden · 2022-02-01T09:39:07Z

That was good timing :) Happy New Year!

If the release is as quiet as the RC, we're good. It is already picked up by e.g. homebrew.

mcuee added this to the 1.0.25 milestone Sep 7, 2020

mcuee added the Release Related to release and milestone label Sep 7, 2020

mcuee pinned this issue Mar 1, 2021

mcuee mentioned this issue Jun 7, 2021

libusb stress test failed #922

Closed

mcuee mentioned this issue Jun 7, 2021

Device still referenced warning when running xusb example under macOS #924

Closed

mcuee mentioned this issue Nov 24, 2021

Zero-length packet in libusb_bulk_transfer #1029

Closed

Mindavi mentioned this issue Dec 2, 2021

Xow: libusb buggy NixOS/nixpkgs#135678

Closed

2 tasks

TehCorwiz mentioned this issue Dec 31, 2021

High CPU load with libusb-1.0.24 medusalix/xow#141

Open

tormodvolden closed this as completed Jan 31, 2022

tormodvolden unpinned this issue Jan 31, 2022

mcuee mentioned this issue May 27, 2022

Install libusb 1.0.24 on Mac (intel) #1146

Closed

Misc: To release 1.0.25 #777

Misc: To release 1.0.25 #777

Comments

mcuee commented Sep 7, 2020 • edited by tormodvolden

mcuee commented Jan 16, 2021

mcuee commented Jan 16, 2021

mcuee commented Jan 16, 2021 • edited

yorickvP commented Feb 6, 2021

mcuee commented Feb 7, 2021 • edited

tormodvolden commented Feb 7, 2021 • edited

mcuee commented Feb 9, 2021

mcuee commented Feb 9, 2021

EmptyVisual commented Apr 14, 2021 • edited

mcuee commented Apr 14, 2021

tormodvolden commented Apr 14, 2021

mcuee commented Apr 14, 2021

mcuee commented Apr 14, 2021

mcuee commented Jun 1, 2021

mcuee commented Jun 5, 2021

mcuee commented Jun 5, 2021 • edited

mcuee commented Jun 5, 2021

mcuee commented Jun 6, 2021

hjelmn commented Jun 6, 2021 • edited

hjelmn commented Jun 6, 2021

hjelmn commented Jun 6, 2021

hjelmn commented Jun 6, 2021

mcuee commented Jun 7, 2021

mcuee commented Jun 7, 2021 • edited

patstew commented Jun 7, 2021

mcuee commented Dec 3, 2021

hjelmn commented Dec 11, 2021

hjelmn commented Dec 11, 2021

mcuee commented Jan 19, 2022

tormodvolden commented Jan 19, 2022

mcuee commented Jan 21, 2022

mcuee commented Jan 21, 2022

LudovicRousseau commented Jan 21, 2022

hjelmn commented Jan 21, 2022

tormodvolden commented Jan 21, 2022

mcuee commented Jan 29, 2022

hjelmn commented Jan 29, 2022

tormodvolden commented Jan 29, 2022

mcuee commented Jan 29, 2022

mcuee commented Jan 29, 2022 • edited

tormodvolden commented Jan 29, 2022

mcuee commented Jan 29, 2022

LudovicRousseau commented Jan 29, 2022

tormodvolden commented Jan 29, 2022 • edited

LudovicRousseau commented Jan 29, 2022

tormodvolden commented Jan 29, 2022

mcuee commented Jan 30, 2022 • edited

mcuee commented Feb 1, 2022

tormodvolden commented Feb 1, 2022

mcuee commented Sep 7, 2020 •

edited by tormodvolden

mcuee commented Jan 16, 2021 •

edited

mcuee commented Feb 7, 2021 •

edited

tormodvolden commented Feb 7, 2021 •

edited

EmptyVisual commented Apr 14, 2021 •

edited

mcuee commented Jun 5, 2021 •

edited

hjelmn commented Jun 6, 2021 •

edited

mcuee commented Jun 7, 2021 •

edited

mcuee commented Jan 29, 2022 •

edited

tormodvolden commented Jan 29, 2022 •

edited

mcuee commented Jan 30, 2022 •

edited