Bug#810445: lirc: please switch to libusb 1.0

[Michael Kolmodin]

On Thu, 12 Jan 2017 20:52:12 +0100 Gianfranco Costamagna 
 wrote:

>
> > That is, is it really, really impossible to use the compatibility
> > package which actually works on Fedora to resolve this?
>
> can you please add more information on that?
> how does it work?
>
> G.


See  #731424

--alec

Bug#810445: lirc: please switch to libusb 1.0

[Gianfranco Costamagna]

> That is, is it really, really impossible to use the compatibility 
> package which actually works on Fedora to resolve this?

can you please add more information on that?
how does it work?

G.



signature.asc
Description: OpenPGP digital signature

Bug#810445: lirc: please switch to libusb 1.0

[Alec Leamas]

On Sat, 9 Jan 2016 01:20:15 +0100 Aurelien Jarno  wrote:
> On 2016-01-09 01:05, Stefan Lippers-Hollmann wrote:

>
> > I'm asking because there are two options:
> >
> > - pushing the current upstream version, with a transition, involving
> > around 30 rdepends, needing sourceful uploads for most of them, and
> > a rather complex device specific config migration, plus some pending
> > packaging work
> >
> > or
> >
> > - backporting (looks to be pretty reasonable) the necessary changes 
for

> > libusb 1.0 to lirc 0.9.0 (or 0.9.1, which 'only' needs the config
> > migration, but not the library transition and the corresponding
> > transition slot).

Some time later, the current upstream version is indeed pushed. This 
resolves a lot of issues, but not this.


Upstream  is still using the 0.1 interfaces. On Fedora, these are 
implemented by a compatibility package on top of the modern 1.0 library. 
However, I have understood that this is not the Debain Way. That said, I 
don't really see the resources upstream which are willing to undertake 
the 0.1 -> 1.0 transition. Part of the problem is that here is driver 
code which requires specific hardware to test.


That is, is it really, really impossible to use the compatibility 
package which actually works on Fedora to resolve this?


--alec

Bug#810445: lirc: please switch to libusb 1.0

[Stefan Lippers-Hollmann]

Hi

On 2016-01-08, Aurelien Jarno wrote:
> Package: lirc
> Version: 0.9.0~pre1-1.2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> lirc 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.
[...]

[ this will be basically the same answer as for libftdi1, so feel free
  to skip reading one ]

What is the rough time frame you have in mind for removing libusb-0.1-4
from unstable?

I'm asking because there are two options:

- pushing the current upstream version, with a transition, involving 
  around 30 rdepends, needing sourceful uploads for most of them, and 
  a rather complex device specific config migration, plus some pending 
  packaging work

or

- backporting (looks to be pretty reasonable) the necessary changes for 
  libusb 1.0 to lirc 0.9.0 (or 0.9.1, which 'only' needs the config 
  migration, but not the library transition and the corresponding 
  transition slot).

Depending on your schedule, I can look into the targeted backports,
but naturally I'd prefer to avoid that (as long as lirc won't be
one of the final blockers).

Regards
Stefan Lippers-Hollmann


pgpqcQgBtZwtO.pgp
Description: Digitale Signatur von OpenPGP

Bug#810445: lirc: please switch to libusb 1.0

[Aurelien Jarno]

On 2016-01-09 01:05, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On 2016-01-08, Aurelien Jarno wrote:
> > Package: lirc
> > Version: 0.9.0~pre1-1.2
> > Severity: wishlist
> > 
> > Dear Maintainer,
> > 
> > lirc 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.
> [...]
> 
> [ this will be basically the same answer as for libftdi1, so feel free
>   to skip reading one ]
> 
> What is the rough time frame you have in mind for removing libusb-0.1-4
> from unstable?

I currently don't have a time frame in mind for libusb 0.1. Ideally that
should be done for stretch, but given the number of involved packages it
might be only for buster. That's why have opened theses bugs with
severity "wishlist".

For libftdi, I hope we can do that before the stretch freeze.

> I'm asking because there are two options:
> 
> - pushing the current upstream version, with a transition, involving 
>   around 30 rdepends, needing sourceful uploads for most of them, and 
>   a rather complex device specific config migration, plus some pending 
>   packaging work
> 
> or
> 
> - backporting (looks to be pretty reasonable) the necessary changes for 
>   libusb 1.0 to lirc 0.9.0 (or 0.9.1, which 'only' needs the config 
>   migration, but not the library transition and the corresponding 
>   transition slot).
> 
> Depending on your schedule, I can look into the targeted backports,
> but naturally I'd prefer to avoid that (as long as lirc won't be
> one of the final blockers).

Don't rush anything for now. I'll send an update once there are less
blockers involved.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: Digital signature