Jonas Malaco
Jonas Malaco
I'm not sure what's going on, other than the client (I think) is trying to use one variant of the protocol we don't yet support. From a quick read of...
@ceremcem I'm sorry that I still haven't looked into this. Can you give me access to a copy of the repository where this happens?
I was able to reproduce the git-receive-pack calls (even though I wasn't yet testing the cache) on both your Gogs instance and GitHub. So it's easier to just add support...
I checked the protocol specification (and its implementation in git) and the `git-receive-pack` service should only be requested for a `push`. The current version of the project only supports `clone`...
I don't understand exactly what's going on here. Is this an API issue (.NET doesn't like that baud rate), or does the device report (somehow) that it wants a lower...
Actually, I don't think that's likely: the bridge [supports baud rates in the 300-1000k range](http://ww1.microchip.com/downloads/en/DeviceDoc/200022228D.pdf), and kursti8/hue-plus seems to use [256k without problems](https://github.com/kusti8/hue-plus/blob/7ce7c4603c6d0ab1da29b0d4080aa05f57bd1760/hue_plus/hue.py#L114).
PyUSB could indeed benefit from higher level and more (immediately) informative errors, but that's needs to go beyond replacing ```py raise USBError(..., LIBUSB_ERROR_PIPE, EPIPE) ``` with ```py raise USBBrokenPipeError() ```...
We already have an open issue for that device: #218. Closing this one to keep the discussion in a single place.
Oh, sorry.
Can you post the output from `lsusb -v` for that device?