Gang,
As I was preparing the screenshots Willem requested, I ran into trouble
connecting my Petrel 2 via BT. The pairing went fine, but when I hit
the Download button, I got "Unsupported operation". I clicked on retry,
to no avail. Only once I restarted subsurface, Download worked but it
came up
Announcements are posted.
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Duh. Some times I hate it when you are obviously right. I'll fix that and make
the Uemis download do the right thing.
--
Sent from my phone
> On Sep 19, 2015, at 16:39, Linus Torvalds
> wrote:
>
>> On Sat, Sep 19, 2015 at 4:32 PM, Dirk Hohndel
Just a point of note as I cannot reproduce this now.
First installation of 4.5 beta2 I got the blue bar at the bottom with the
message: Cannot connect to cloud server, working with local copy.
Then I opened a local file then went back to File, Open Cloud Storage and
got a red bar down the bottom
Just edited (again) to make the test cases more clear and add an extra bit
of detail.
Sorry for the spamming, I should proofread twice before sending :)
From: subsurface [mailto:subsurface-boun...@subsurface-divelog.org] On
Behalf Of Steve
Sent: Sunday, 20 September 2015 1:48 PM
To:
So I tested the Uemis download with force and retry and a couple of
iterations of that... it all looked good. And then I accepted the download
and Subsurface hung. Attached a debugger and it's clearly hung in deco
calculations. Specifically, and that's what's puzzling me, in
Sorry, had an invalid address for Robert...
On Sat, Sep 19, 2015 at 10:29:22PM -0700, Dirk Hohndel wrote:
> So I tested the Uemis download with force and retry and a couple of
> iterations of that... it all looked good. And then I accepted the download
> and Subsurface hung. Attached a debugger
Good morning,On 20 Sep 2015, at 07:29, Dirk Hohndel wrote:Robert, any comment on this?just got out of bed, before the first coffee. This patch prevents the deco calculation (which takes a lot of time) but of course does not help with the original problem. Hope to have some time
-Original Message-
From: Claudiu Olteanu [mailto:olteanu.vasilica.clau...@gmail.com]
Sent: Sunday, 20 September 2015 2:10 AM
To: Subsurface Mailing List
Cc: Dirk Hohndel ; Steve
Subject: [PATCH] Fix
On Sun, Sep 20, 2015 at 01:18:00PM +0930, Steve wrote:
>
> Thanks Claudiu, these patches fixed the issue perfectly. Both HW OSTC and SW
> Petrel devices worked well.
Thanks for verifying! The patches made it to Beta 2, so hopefully we'll
get some more testing. So far there appears to be only
Can I get this as a patch with good commit message and SOB, please?
Thanks
/D
On Sat, Sep 19, 2015 at 05:15:30PM -0700, Linus Torvalds wrote:
> On Sat, Sep 19, 2015 at 4:47 PM, Dirk Hohndel wrote:
> > Duh. Some times I hate it when you are obviously right. I'll fix that and
Just edited to make the test cases more clear and add an extra bit of
detail.
From: subsurface [mailto:subsurface-boun...@subsurface-divelog.org] On
Behalf Of Steve
Sent: Sunday, 20 September 2015 1:48 PM
To: 'Subsurface Mailing List'
Subject: Beta 2 testing
On Sat, Sep 19, 2015 at 4:32 PM, Dirk Hohndel wrote:
>
> IIRC you still need to manually uncheck it after the first run through.
> I don't think this is fixed, yet.
So quite frankly, I'm pretty sure that is entirely broken.
If you uncheck the "force download all dives"
> On Sep 19, 2015, at 4:24 PM, Linus Torvalds
> wrote:
>
> On Sat, Sep 19, 2015 at 4:22 PM, Dirk Hohndel wrote:
>>
>> It quite obviously needs an
>>
>> if (nds && strstr(...))
>>
>> could you test that and send a patch if it fixes it?
>
> I
On Sat, Sep 19, 2015 at 09:15:59PM -0700, Linus Torvalds wrote:
> On Sat, Sep 19, 2015 at 9:04 PM, Dirk Hohndel wrote:
> > Can I get this as a patch with good commit message and SOB, please?
>
> Ok, done, but I do think more testing would be good.
> And hey, I think the code
On Sat, Sep 19, 2015 at 4:47 PM, Dirk Hohndel wrote:
> Duh. Some times I hate it when you are obviously right. I'll fix that and
> make the Uemis download do the right thing.
Wait, I have a patch already.
This is *NOT*TESTED*. It's still downloading without this patch (and
On Sat, Sep 19, 2015 at 5:15 PM, Linus Torvalds
wrote:
>
> This is *NOT*TESTED*. It's still downloading without this patch (and
> with the manual clearing), and I wanted to let that go on.
Ok, finally tested. The downloading took forever, but part of it was
that
On Sat, Sep 19, 2015 at 9:04 PM, Dirk Hohndel wrote:
> Can I get this as a patch with good commit message and SOB, please?
Ok, done, but I do think more testing would be good.
And hey, I think the code looks more obvious, but extra review isn't a
bad idea either.
From: Linus Torvalds
Date: Sat, 19 Sep 2015 21:09:58 -0700
Subject: [PATCH 2/2] uemis downloader: start downloading using the correct dive
ID
The logic to pick the initial dive ID for the uemis downloader was very
confused, and did not work at all when restarting
On Sat, Sep 19, 2015 at 4:22 PM, Dirk Hohndel wrote:
>
> It quite obviously needs an
>
> if (nds && strstr(...))
>
> could you test that and send a patch if it fixes it?
I did that already, it's still downloading.
Well, I actually used "if (nds && nds->name && strstr.."
Good morning.
2015-09-19 5:42 GMT+02:00 Dirk Hohndel :
> On Fri, Sep 18, 2015 at 06:37:11PM -0700, Dirk Hohndel wrote:
> > So it looks like I broke things when I worked on better error messages.
> But I ran make test afterwards.
> >
> > I'll investigate after our guests leave
>
On Sat, Sep 19, 2015 at 6:42 AM, Dirk Hohndel wrote:
> On Fri, Sep 18, 2015 at 06:37:11PM -0700, Dirk Hohndel wrote:
>> So it looks like I broke things when I worked on better error messages. But
>> I ran make test afterwards.
>>
>> I'll investigate after our guests leave
>
>
> On 19 Sep 2015, at 5:42, Dirk Hohndel wrote:
>
> On Fri, Sep 18, 2015 at 06:37:11PM -0700, Dirk Hohndel wrote:
>> So it looks like I broke things when I worked on better error messages. But
>> I ran make test afterwards.
>>
>> I'll investigate after our guests leave
>
>
> On Sep 19, 2015, at 01:29, Miika Turkia wrote:
>
>> Puzzled. Can others please do some more testing? I'll delay the Beta 2 at
>> least until tomorrow...
>
> Opening the cloud storage and saving a trivial mod takes 20 to 30
> seconds with no progress bar, but it seems
Am 19.09.2015 um 01:48 schrieb Dirk Hohndel:
On Sep 18, 2015, at 2:38 PM, Guido Lerch wrote:
My OSTC 3 does not have blue tooth does it ?
I believe only the newest models from Heinrichs & Weikamp support Bluetooth.
Matthias?
If the OSTC3 has USB it has no Bluetooth,
Signed-off-by:Salvador Cuñat
Signed-off-by: Salvador Cuñat
---
Documentation/user-manual_es.txt | 235 +++
1 file changed, 139 insertions(+), 96 deletions(-)
diff --git a/Documentation/user-manual_es.txt
On Sat, Sep 19, 2015 at 12:34:58AM +0300, Guido Lerch wrote:
>
> Have you seen my small patch ?
>
> Will work on top of what you do :-)
Did I miss anything you sent? I thought I applied even the ones hiding in
emails without [PATCH] in the Subject :-)
/D
On Sat, Sep 19, 2015 at 04:19:27PM -0700, Linus Torvalds wrote:
> On Fri, Sep 18, 2015 at 10:34 AM, Dirk Hohndel wrote:
> >
> > Very successfully. I hope Linus will give it another try before our next
> > dive trip (we are leaving next week).
>
> I'm not having as much luck.
>
On Fri, Sep 18, 2015 at 10:34 AM, Dirk Hohndel wrote:
>
> Very successfully. I hope Linus will give it another try before our next
> dive trip (we are leaving next week).
I'm not having as much luck.
I get a SIGSEGV when downloading from my Uemis. I re-ran it under gdb,
and it
On Sat, Sep 19, 2015 at 4:24 PM, Linus Torvalds
wrote:
>
> Well, I actually used "if (nds && nds->name && strstr.." because I
> wasn't 100% sure that a dive site is guaranteed to have a non-NULL
> name.
Ok, so with that, things are looking up a bit. It now
From: Linus Torvalds
Date: Sat, 19 Sep 2015 21:08:03 -0700
Subject: [PATCH 1/2] uemis downloader: avoid NULL pointer dereference
The uemis downloader blindly just did a strstr on 'nds->name', even if
there wasn't necessarily a dive location at all.
Add the proper
Hi there,
There was an issue reported by Steve regarding the Bluetooth address
on Windows 10 platforms. The first patch should fix the problem.
Claudiu
0001-Fix-Bluetooth-address-truncation-issues-on-Windows.patch
Description: Binary data
0002-Rename-BTH_ADDR_STR_LEN-macro.patch
Description:
Patches look good.
On Saturday 19 September 2015 19:40:05 Claudiu Olteanu wrote:
> Hi there,
>
> There was an issue reported by Steve regarding the Bluetooth address
> on Windows 10 platforms. The first patch should fix the problem.
>
> Claudiu
--
Thiago Macieira - thiago (AT) macieira.info -
33 matches
Mail list logo