Your message dated Mon, 14 Nov 2011 14:07:29 +
with message-id <1321279649.2885.10.camel@deadeye>
and subject line Re: Bug#647513: fixed ?
has caused the Debian Bug report #647513,
regarding TX watchdog fires for ipheth after phone upgraded to iOS 5
to be marked as done.
This means th
ux-2.6-3.0.0/debian/build/source_amd64_none/net/sched/sch_generic.c:255
dev_watchdog+0xe9/0x148()
Nov 3 14:16:51 thib kernel: [ 371.824027] Hardware name: OptiPlex 780
Nov 3 14:16:51 thib kernel: [ 371.824029] NETDEV WATCHDOG: eth1 (ipheth):
transmit queue 0 timed out
[...]
Diego, please can yo
Processing commands for cont...@bugs.debian.org:
> retitle 647513 TX watchdog fires for ipheth after phone upgraded to iOS 5
Bug #647513 [linux-2.6] linux-image-3.0.0-1-amd64: kernel error when I plug
iphone with IOS5 firmware and Tethering
Changed Bug title to 'TX watchdog fires fo
sch_generic.c:255
> dev_watchdog+0xe9/0x148()
> Nov 3 14:16:51 thib kernel: [ 371.824027] Hardware name: OptiPlex 780
> Nov 3 14:16:51 thib kernel: [ 371.824029] NETDEV WATCHDOG: eth1 (ipheth):
> transmit queue 0 timed out
[...]
Diego, please can you investigate this.
Ben.
s the user with some UI in a
> form like: Do you want to pair with device "Foo Bar's iPhone"? [Yes][No]
Is this "pairing" any different from the pairing we do with devices that
are automounted through gvfs?
Bonus question is, can you use ipheth on the iPod touch/iPad
On Thu, 2010-05-27 at 10:38 +0100, Peter Robinson wrote:
> On Fri, Apr 30, 2010 at 5:33 AM, Paul McEnery wrote:
> > On 27 April 2010 17:39, Julien BLACHE wrote:
> >> Olivier Galibert wrote:
[SNIP]
> > Is anyone prepared to commit to including a pairing utility and the
> > udev rule as part of li
On Fri, Apr 30, 2010 at 5:33 AM, Paul McEnery wrote:
> On 27 April 2010 17:39, Julien BLACHE wrote:
>> Olivier Galibert wrote:
>>
>> Hi,
>>
>>> Why can't ipheth just depend on libimobiledevice-utils ? It *is* a
>>> functional dependency after a
On 27 April 2010 17:39, Julien BLACHE wrote:
> Olivier Galibert wrote:
>
> Hi,
>
>> Why can't ipheth just depend on libimobiledevice-utils ? It *is* a
>> functional dependency after all, even if they're not communicating
>> directly with each other.
&g
On Tue, Apr 27, 2010 at 06:39:46PM +0200, Julien BLACHE wrote:
> Olivier Galibert wrote:
>
> Hi,
>
> > Why can't ipheth just depend on libimobiledevice-utils ? It *is* a
> > functional dependency after all, even if they're not communicating
> > direct
Olivier Galibert wrote:
Hi,
> Why can't ipheth just depend on libimobiledevice-utils ? It *is* a
> functional dependency after all, even if they're not communicating
> directly with each other.
The ipheth-dkms package will disappear because ipheth has been accepted
upst
On Tue, Apr 27, 2010 at 03:14:07PM +0100, Paul McEnery wrote:
> How about this then libimobiledevice-utils supplying the udev rule
> and pairing utility, and providing a virtual package which "Provides:
> ipheth-support"? Maybe the provides bit is not required...
Why can&#
.
>>>> > It cannot simply be assumed that if usbmuxd is installed that gvfs,
>>>> > libgpod, etc will also be installed, let alone executed before the
>>>> > user attempts to connect using ipheth. The only way that these
>>>> > assumptions can be met,
vfs,
>>> > libgpod, etc will also be installed, let alone executed before the
>>> > user attempts to connect using ipheth. The only way that these
>>> > assumptions can be met, is with the appropriate dependencies.
>>> >
>>> > The way that
t application must exist in some package. That package
>> > will need to be a dependency of usbmuxd (unless usbmuxd provides it).
>> > It cannot simply be assumed that if usbmuxd is installed that gvfs,
>> > libgpod, etc will also be installed, let alone executed before the
&g
gt; will need to be a dependency of usbmuxd (unless usbmuxd provides it).
> > It cannot simply be assumed that if usbmuxd is installed that gvfs,
> > libgpod, etc will also be installed, let alone executed before the
> > user attempts to connect using ipheth. The only way that these
"Martin S." wrote:
Hi,
> Why not add an udev rule to the ipheth package which checks for the
> "USBMUX_SUPPORTED" flag and the ipheth module being "added", then calls
> the idevicepairing tool to pair?
>
> Thus the ipheth module would simply depe
annot simply be assumed that if usbmuxd is installed that gvfs,
> libgpod, etc will also be installed, let alone executed before the
> user attempts to connect using ipheth. The only way that these
> assumptions can be met, is with the appropriate dependencies.
>
> The way tha
ich performs
the pairing, that application must exist in some package. That package
will need to be a dependency of usbmuxd (unless usbmuxd provides it).
It cannot simply be assumed that if usbmuxd is installed that gvfs,
libgpod, etc will also be installed, let alone executed before the
us
d/iphone rules for various bits and then the
actual pairing utill would be in libimobiledevice. There would be no
extra dependencies.
> At this point I'm working on dropping the ipheth-dkms package and
> keeping only ipheth-utils which provides the udev rules and pariing
> utility.
As d
On 24 April 2010 08:00, Peter Robinson wrote:
> On Sat, Apr 24, 2010 at 6:46 AM, Paul McEnery wrote:
>> 2010/4/22 Ben Hutchings :
>>> On Fri, 2010-04-02 at 21:40 +0100, Ben Hutchings wrote:
>>>> On Fri, 2010-04-02 at 21:09 +0100, Paul McEnery wrote:
>>>
Paul McEnery wrote:
Hi,
> My initial thoughts are to simply drop the dependency on the dkms
> package, but ipheth will now be in every kernel going forward, so
> there will not be any need for it. Any advice would be much
> appreciated. Please include me in any reply as I'm no
On Sat, Apr 24, 2010 at 6:46 AM, Paul McEnery wrote:
> 2010/4/22 Ben Hutchings :
>> On Fri, 2010-04-02 at 21:40 +0100, Ben Hutchings wrote:
>>> On Fri, 2010-04-02 at 21:09 +0100, Paul McEnery wrote:
>>> [...]
>>> > 1. Keep the ipheth-utils package and drop
Since ipheth has now been accepted into the mainline kernel, I see a
couple of choices for the ipheth package:
1. Drop ipheth-dkms altogether.
2. Drop the dependency on ipheth-dkms in the ipheth-utils package.
My initial thoughts are to simply drop the dependency on the dkms
package, but ipheth
2010/4/22 Ben Hutchings :
> On Fri, 2010-04-02 at 21:40 +0100, Ben Hutchings wrote:
>> On Fri, 2010-04-02 at 21:09 +0100, Paul McEnery wrote:
>> [...]
>> > 1. Keep the ipheth-utils package and drop ipheth-dkms when ipheth
>> > makes it into the mainline kernel. Gi
On Fri, 2010-04-02 at 21:40 +0100, Ben Hutchings wrote:
> On Fri, 2010-04-02 at 21:09 +0100, Paul McEnery wrote:
> [...]
> > 1. Keep the ipheth-utils package and drop ipheth-dkms when ipheth
> > makes it into the mainline kernel. Given that mainline inclusion could
> >
kernel space. That said, and given the
>> maturity of ipheth, would it be fair to say that ipheth is the way
>> forward in terms of i tethering?
>
> Hi Paul,
>
> Reading the thread that you posted, it seems like the original author
> agreed to "kind of" support a kernel-s
> faster kernel space is, but this was never substantiated, and there
> was never a conclusion to the discussion. IIRC the user space driver
> was something that didn't integrate with the other components such as
> NetworkManager in quite the same way that ipheth does. Ipheth is jus
On 04/02/2010 10:09 PM, Paul McEnery wrote:
[...]
> Without wanting to say anything on
> Bradley's behalf, it appeared as if he was in support of the tethering
> driver being implemented in kernel space. That said, and given the
> maturity of ipheth, would it be fair to say that
On Fri, 2010-04-02 at 21:09 +0100, Paul McEnery wrote:
[...]
> 1. Keep the ipheth-utils package and drop ipheth-dkms when ipheth
> makes it into the mainline kernel. Given that mainline inclusion could
> take a while, users (of Debian at least) could start to benefit almost
> immediate
On 2 April 2010 15:11, "L. Alberto Giménez" wrote:
> On 04/01/2010 10:20 PM, Paul McEnery wrote:
>>
>> Ben, one of the reasons that I was slow to respond to the call to
>> integrate ipheth into the mainline kernel is that I don't believe that
>> it belo
On 04/01/2010 10:20 PM, Paul McEnery wrote:
>
> Ben, one of the reasons that I was slow to respond to the call to
> integrate ipheth into the mainline kernel is that I don't believe that
> it belongs there. It's far too dependent on other bits and pieces in
> order to
On Thu, 2010-04-01 at 13:40 -0700, Daniel Borca wrote:
> Martin,
>
> ipheth needs ValidatePair, not Pair
> http://libiphone.lighthouseapp.com/projects/27916/tickets/89-provide-access-to-validatepair#ticket-89-9
> http://github.com/dgiagio/ipheth/blob/master/ipheth-pair/ipheth-pair
Martin,
ipheth needs ValidatePair, not Pair
http://libiphone.lighthouseapp.com/projects/27916/tickets/89-provide-access-to-validatepair#ticket-89-9
http://github.com/dgiagio/ipheth/blob/master/ipheth-pair/ipheth-pair.c
Regards,
Daniel Borca
--- On Thu, 4/1/10, Paul McEnery wrote:
> F
On 1 April 2010 18:23, Martin S. wrote:
> On Thu, 2010-04-01 at 14:30 +0100, Paul McEnery wrote:
>> On 1 April 2010 14:07, Ben Hutchings wrote:
>> > Paul,
>> >
>> > I missed you talking about ipheth on IRC earlier.
>> >
>> > I've seen th
On Thu, 2010-04-01 at 14:30 +0100, Paul McEnery wrote:
> On 1 April 2010 14:07, Ben Hutchings wrote:
> > Paul,
> >
> > I missed you talking about ipheth on IRC earlier.
> >
> > I've seen the submission of ipheth on the netdev mailing list, and made
&g
On Thu, Apr 1, 2010 at 2:30 PM, Paul McEnery wrote:
> On 1 April 2010 14:07, Ben Hutchings wrote:
>> Paul,
>>
>> I missed you talking about ipheth on IRC earlier.
>>
>> I've seen the submission of ipheth on the netdev mailing list, and made
>> some
On 1 April 2010 14:07, Ben Hutchings wrote:
> Paul,
>
> I missed you talking about ipheth on IRC earlier.
>
> I've seen the submission of ipheth on the netdev mailing list, and made
> some comments on it there. If it is accepted, we can include it in the
> Debian kern
Paul,
I missed you talking about ipheth on IRC earlier.
I've seen the submission of ipheth on the netdev mailing list, and made
some comments on it there. If it is accepted, we can include it in the
Debian kernel packages and there will then be no need for ipheth-dkms.
You'll still n
On Fri, 2010-01-22 at 20:43 +, Paul McEnery wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Paul McEnery
>
>
> * Package name: ipheth
> Version : 0.1
> Upstream Author : Diego Giagio
> Upstream Author : Daniel Borca
> * URL
39 matches
Mail list logo
