FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 05-27-2012, 06:12 PM
Samuli Suominen
 
Default dev-libs/libusbx:1 the default provider for virtual/libusb:1 (for ~arch)

Fedora rawhide and ArchLinux switched to libusbx and followed suit in
our virtual/libusb:1.

Debian is considering the switch also. We'll see...

I've been in contact with the new maintainer, and he assured me the
compability will be kept for libusb-compat.


Happy testing,

# emerge -C dev-libs/libusb:1
# emerge -1 dev-libs/libusbx:1

Perhaps a Portage News item worthy after stabilization later on...
I have no plans to rush this.

- Samuli
 
Old 05-28-2012, 12:16 AM
Zac Medico
 
Default dev-libs/libusbx:1 the default provider for virtual/libusb:1 (for ~arch)

On 05/27/2012 11:12 AM, Samuli Suominen wrote:
> Fedora rawhide and ArchLinux switched to libusbx and followed suit in
> our virtual/libusb:1.
> Debian is considering the switch also. We'll see...
>
> I've been in contact with the new maintainer, and he assured me the
> compability will be kept for libusb-compat.
>
> Happy testing,
>
> # emerge -C dev-libs/libusb:1
> # emerge -1 dev-libs/libusbx:1

I've tried this on my laptop, and afterwards it wouldn't suspend to ram
when it was supposed to. I didn't do any real troubleshooting, so I'm
just mentioning it here in case it helps someone else recognize the
source of the problem. This was with sys-power/upower-0.9.16 and
dev-libs/libusbx-1.0.11 (I didn't try to rebuild upower after switching
from dev-libs/libusb-1.0.9 to dev-libs/libusbx-1.0.11).
--
Thanks,
Zac
 
Old 05-28-2012, 09:02 AM
Pacho Ramos
 
Default dev-libs/libusbx:1 the default provider for virtual/libusb:1 (for ~arch)

El dom, 27-05-2012 a las 17:16 -0700, Zac Medico escribió:
> On 05/27/2012 11:12 AM, Samuli Suominen wrote:
> > Fedora rawhide and ArchLinux switched to libusbx and followed suit in
> > our virtual/libusb:1.
> > Debian is considering the switch also. We'll see...
> >
> > I've been in contact with the new maintainer, and he assured me the
> > compability will be kept for libusb-compat.
> >
> > Happy testing,
> >
> > # emerge -C dev-libs/libusb:1
> > # emerge -1 dev-libs/libusbx:1
>
> I've tried this on my laptop, and afterwards it wouldn't suspend to ram
> when it was supposed to. I didn't do any real troubleshooting, so I'm
> just mentioning it here in case it helps someone else recognize the
> source of the problem. This was with sys-power/upower-0.9.16 and
> dev-libs/libusbx-1.0.11 (I didn't try to rebuild upower after switching
> from dev-libs/libusb-1.0.9 to dev-libs/libusbx-1.0.11).

Maybe you should open a bug report for it to not forget that problem
(now that finally my laptop suspends even with upstream kernel and
without TOI wouldn't like to see it magically failing again without
remember the real culprit )
 
Old 05-28-2012, 08:50 PM
Zac Medico
 
Default dev-libs/libusbx:1 the default provider for virtual/libusb:1 (for ~arch)

On 05/28/2012 02:02 AM, Pacho Ramos wrote:
> El dom, 27-05-2012 a las 17:16 -0700, Zac Medico escribió:
>> On 05/27/2012 11:12 AM, Samuli Suominen wrote:
>>> Fedora rawhide and ArchLinux switched to libusbx and followed suit in
>>> our virtual/libusb:1.
>>> Debian is considering the switch also. We'll see...
>>>
>>> I've been in contact with the new maintainer, and he assured me the
>>> compability will be kept for libusb-compat.
>>>
>>> Happy testing,
>>>
>>> # emerge -C dev-libs/libusb:1
>>> # emerge -1 dev-libs/libusbx:1
>>
>> I've tried this on my laptop, and afterwards it wouldn't suspend to ram
>> when it was supposed to. I didn't do any real troubleshooting, so I'm
>> just mentioning it here in case it helps someone else recognize the
>> source of the problem. This was with sys-power/upower-0.9.16 and
>> dev-libs/libusbx-1.0.11 (I didn't try to rebuild upower after switching
>> from dev-libs/libusb-1.0.9 to dev-libs/libusbx-1.0.11).
>
> Maybe you should open a bug report for it to not forget that problem
> (now that finally my laptop suspends even with upstream kernel and
> without TOI wouldn't like to see it magically failing again without
> remember the real culprit )

I've got it working now. The first time, when I had the suspend to ram
issue, I did `emerge -1 dev-libs/libusbx:1` without unmerging libusb:1
first. The second time, I unmerged libusb:1 first (like Samuli's
instructions said), and since then suspend to ram works fine.
--
Thanks,
Zac
 
Old 05-30-2012, 09:20 PM
Mike Frysinger
 
Default dev-libs/libusbx:1 the default provider for virtual/libusb:1 (for ~arch)

On Sunday 27 May 2012 14:12:46 Samuli Suominen wrote:
> Fedora rawhide and ArchLinux switched to libusbx and followed suit in
> our virtual/libusb:1.

sad that we can't get these things merged. maybe we need to convince dsd to
hand over the reigns ?
-mike
 
Old 05-30-2012, 09:56 PM
Mike Frysinger
 
Default dev-libs/libusbx:1 the default provider for virtual/libusb:1 (for ~arch)

On Wednesday 30 May 2012 17:41:18 Peter Stuge wrote:
> Mike Frysinger wrote:
> > > Fedora rawhide and ArchLinux switched to libusbx and followed
> > > suit in our virtual/libusb:1.
> >
> > sad that we can't get these things merged. maybe we need to
> > convince dsd to hand over the reigns ?
>
> It seems that some don't know that dsd made me co-maintainer in
> libusb some months after he created the 1.0.8 release.
>
> I've been working hard on libusb since before 1.0.8. I joined libusb
> in 2004 and was already asked by Johannes (the 0.1 author) to be
> maintainer in 2007, but declined.
>
> The fork is a long story. I commented in the Arch ticket for their
> switch, and the libusbx lead maintainer replied there today. I also
> had a chat with Samuli and marienz@g.o on IRC about keeping libusb
> as the default provider for virtual/libusb:1.
>
> I'm working on a blog post with what I think are some key facts for
> everyone with an interest in the libusb API. The fork is, like the
> libusb-1.0.9 release, a month old, and of course there was a sudden
> surge in activity when Hans (Fedora libusb package maintainer and
> now libusbx maintainer) blogged about the fork, which I wasn't quite
> prepared for. Hold on, more information coming shortly.

thanks!
-mike
 

Thread Tools




All times are GMT. The time now is 05:13 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org