This list should stay empty (except for the virtual and blockers): http://qa-reports.gentoo.org/output/genrdeps/dindex/dev-libs/libusb http://qa-reports.gentoo.org/output/genrdeps/rindex/dev-libs/libusb The ebuilds should use virtual/libusb:1, also see bug 417123...
09:16 <@ssuominen> Zero_Chaos: You need to use virtual/libusb:1 instead of dev-libs/libusb to allow the more recent version, dev-libs/libusbx 09:16 <@ssuominen> What is unclear? 09:16 <@ssuominen> libusbx is an upgrade over libusb 09:17 <@ssuominen> the virtual exists for a reason... 09:21 <@ssuominen> use virtual/libusb in ebuilds... 09:21 <@ssuominen> they are drop-in-replacements 09:21 <@Zero_Chaos> ssuominen: you are 100% certain that it is a drop in replacement and I don't need to test? 09:22 <@ssuominen> yes I don't mean to pass blame but my internet sucks too bad to test properly right now so please go easy on me if this breaks horribly. Defcon isn't the best place to be doing this... + 28 Jul 2012; Rick Farina <zerochaos@gentoo.org> + kismet-ubertooth-0.0_p534.ebuild, kismet-ubertooth-9999.ebuild: + adjust libusb dep to fix bug #428402 + 28 Jul 2012; Rick Farina <zerochaos@gentoo.org> ubertooth-0.0_p534.ebuild, + ubertooth-9999.ebuild: + adjust libusb dep to fix bug #428402
(In reply to comment #1) > 09:16 <@ssuominen> Zero_Chaos: You need to use virtual/libusb:1 instead of > dev-libs/libusb to allow the more recent version, dev-libs/libusbx > 09:16 <@ssuominen> What is unclear? > 09:16 <@ssuominen> libusbx is an upgrade over libusb I can not understand hth ssuominen can say this. Even though I (the libusb maintainer) have explained all the facts to him personally, he writes this which really sounds like he either did not understand (I used simple words) or he did not want to understand (what's that about?).. libusbx is not an upgrade over libusb. In fact, the current version of libusbx has a serious error where it's libusb.h pollutes the global namespace, causing among other things anything that uses libusb-compat-0.1 to fail to build. I agree that the virtual is a good thing, again Gentoo is about choice, but ssuominen, you *really* need to stop spreading such nonsense. I expect you to be eager to learn all the facts. Again, I am not against the fix, and I am not against the virtual. The virtual is a good thing, and the commit is good. However saying that libusbx is an upgrade over libusb is repeating the libusbx propaganda, which I didn't expect a Gentoo developer to fall for so easily.
(In reply to comment #2) > (In reply to comment #1) > > 09:16 <@ssuominen> Zero_Chaos: You need to use virtual/libusb:1 instead of > > dev-libs/libusb to allow the more recent version, dev-libs/libusbx > > 09:16 <@ssuominen> What is unclear? > > 09:16 <@ssuominen> libusbx is an upgrade over libusb > > I can not understand hth ssuominen can say this. Even though I (the libusb > maintainer) have explained all the facts to him personally, he writes this > which really sounds like he either did not understand (I used simple words) > or he did not want to understand (what's that about?).. > > libusbx is not an upgrade over libusb. I disagree, in both packaging and git wise for reasons you've laid out yourself: > In fact, the current version of > libusbx has a serious error where it's libusb.h pollutes the global > namespace, causing among other things anything that uses libusb-compat-0.1 > to fail to build. Not a problem for us: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libusb-compat/files/libusb-0.1-libusbx.patch?revision=1.5&view=markup And fixed for upcoming 1.0.13: https://github.com/libusbx/libusbx/commit/7ec94a45ed8155e7a1d4d5d75575099b09c78834 After release of 1.0.13 we adjust libusb-compat to the new names. If orig. libusb is not up-to-date with the changes at this point, it really doesn't satisfy the basic requirement of the virtual anymore, about having same public API in the providers.
(In reply to comment #3) > > libusbx is not an upgrade over libusb. > > I disagree, in both packaging and git wise for reasons you've laid out > yourself: > > > In fact, the current version of > > libusbx has a serious error where it's libusb.h pollutes the global > > namespace, causing among other things anything that uses libusb-compat-0.1 > > to fail to build. I'm sorry, but I just don't understand how you can consider namespace pollution to be an upgrade in packaging or git wise. > Not a problem for us: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libusb- > compat/files/libusb-0.1-libusbx.patch?revision=1.5&view=markup I for one disagree with this patch. Since libusbx have removed the namespace pollution I think it would make more sense to backport that upstream patch libusbx rather than to patch other packages' internal definitions. > And fixed for upcoming 1.0.13: > > https://github.com/libusbx/libusbx/commit/ > 7ec94a45ed8155e7a1d4d5d75575099b09c78834 Yes, libusbx fixed the namespace pollution rather quickly after you filed the bug against libusb and I explained the problem in more detail and redirected you to libusbx. > After release of 1.0.13 we adjust libusb-compat to the new names. libusb-compat-0.1 does not need any adjusting. The two sets of names are completely unrelated. I thought you had understood this. I guess I should have been more clear about this, but I figured that you had looked at the code so you understood the issue. > If orig. libusb is not up-to-date with the changes at this point, it really > doesn't satisfy the basic requirement of the virtual anymore, about having > same public API in the providers. Do I really understand correctly that you thus encourage different virtual providers to race each other to invent new and maximally incompatible API, in order to kick the other providers out? That would surprise me very much.
And the bug came back again :( ubertooth-0.0_p534.ebuild: dfu? ( >=dev-libs/libusb-1.0.8 ) ubertooth-9999.ebuild: dfu? ( >=dev-libs/libusb-1.0.8 )
Fixed again and added missing inherit for multilib (Was these ebuilds ever tested? No way these ever installed correctly)
(In reply to comment #6) > Fixed again and added missing inherit for multilib > It appears it isn't "fixed again" so much as "fixed properly". When I initially fixed this I didn't fix the dfu conditional dep at all. My fault, sorry about that. > (Was these ebuilds ever tested? No way these ever installed correctly) Believe it or not, I test everything before commit. I have no idea how my environment didn't error on this, but it didn't. I must have had things pretty contaminated somehow, but that is possible. I don't mind you suggesting I'm incompetent but please don't suggest I don't test, it is one of the few things about my skills which I will refute. Thanks for the fixes, it is welcome as always.
