libusbx is now deprecated as the code merged back to libusb since version 1.0.18, so, please test and stabilize: =dev-libs/libusb-1.0.18 thanks!
Stable for HPPA.
amd64 stable
arm stable
x86 stable
sparc stable
ppc64 stable
Disclosure: I'm the maintainer of libusb.org and I released libusb-1.0.9. Samuli, (In reply to Samuli Suominen from comment #0) > libusbx is now deprecated as the code merged back to libusb since version > 1.0.18, This is an outright lie. Please do look at actual facts instead of simply repeating libusbx propaganda. I do think you owe Gentoo at least that much. There has been no such thing as a merge between libusbx and libusb. What has happened is a hostile takeover of the libusb sourceforge project by the libusbx developers, and they have released the current libusbx code as libusb-1.0.18. > so, please test and stabilize: > > =dev-libs/libusb-1.0.18 As bug #497170 shows the libusbx developers aren't on top of their game. I guess the reason they reject me is because I saw the bugs coming a long time ago and didn't want such issues in libusb. I understand that it is rewarding to immediately run after the next new shiny thing, but I do think it would be prudent for Gentoo to actually pay a bit more attention to details, and *not* stabilize a package which clearly isn't stable. Of course I realize that nothing I say will stop you from running yourself straight into the wall. Sad face.
Peter, need more clarification about this situation, what was 1.0.17-1.0.18 releases? the ones not merged or forked by libusbx. 1.0.9 is the only genuine libusb release?
Hi Oleg, (In reply to Oleg from comment #8) > Peter, need more clarification about this situation, what was 1.0.17-1.0.18 > releases? the ones not merged or forked by libusbx. 1.0.9 is the only > genuine libusb release? Yes, the last real release from me/libusb.org is 1.0.9. Nathan Hjelm who wrote the OS X code made several 1.0.16rc* tarballs on libusb.org while he was working on adding hotplug support, initially with the libusb.org code. But his code was not releaseable and I had told him so. Eventually he proceeded to removed me from the libusb SF project and added the libusbx developers. He reworked his hotplug code onto the libusbx codebase. All releases after 1.0.9 are essentially libusbx. 1.0.17 only exists for libusbx. 1.0.18 exists both from libusbx and from libusb on SF and libusb.info. The libusbx developers registered libusb.info and promote this as the main site for libusb since they took over the SF project. The two 1.0.18 tarballs are identical save for branding. If you ask the libusbx forkers who now control the libusb SF project they will say that I am no longer the maintainer of libusb and that what they do is the real libusb now. It's true that I've been removed from the SF project but I still control libusb.org and I'm trying to decide on some way to make my continued work on the source code available. I have no time to fight with the libusbx guys. I also use the libusb-1.0 API and I can't deploy the libusbx code in production.
this bug is about replacing libusbx-1.0.17 (old stable) -> libusb-1.0.18 (new stable) about moving in from libusbx codebase, to another libusbx codebase release we have packages using the new codebase, like qemu i'm not going to comment on the libusb internal politics, who owns sf.net page, who owns libusb name, ... i've always said i'll watch how it plays out, and it looks the libusbx folks are on the winning side as to having access to sf.net, and being used in all the major distributions and with packages now using their code, excluding use of 1.0.9, it doesn't look too good for the old libusb it's still a nice longterm release, and we'll keep it in tree for an extended time remaining arches, please just go on with the bug, this is not the place to discuss it (as this is about moving from usbx codebase .17 to usbx codebase .18)
stabilize only after fixing what 1.0.18 breaks, look 497170 for example.
(In reply to Oleg from comment #11) > stabilize only after fixing what 1.0.18 breaks, look 497170 for example. seen it, that's why I'm considering adding package.use.mask of 'udev' for libusb for now, to retain the old behavior. one bug is hardly an indicator of anything.
would need to open '1.0.9 porting' Tracker bug, and bugs for heimdall, qemu, and whatever else is using the new usbx codebase to reverse them, as in, be compatible with bothkind of libusb headers: as there have been some sane changes like moving the logging interfaces from private to public headers, changes that upstreams are currently doing to be compatible with "the new libusb 1.0.18" if you are intrested in thiskind of endeavour, please go ahead, it would certainly lenghten the time we can keep 1.0.9 around :)
ia64 stable
alpha stable
ppc stable. Closing.
