Re: 4.8.1 planning

2018-07-13 Thread Linus Torvalds 
On Thu, Jul 12, 2018 at 9:59 PM Dirk Hohndel  wrote:
>
> Can I get a commit for this, Linus? :-)

Pull request done.

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Dirk Hohndel 
> Hooray, this seems to work.

Excellent!

Can I get a commit for this, Linus? :-)

> But, as I downloaded everything that is available on the OSTC sport, it seems 
> that the oldest dives do not have the dive profile. Does the sport keep the 
> max depth and time information on log when it needs to start overwriting? I 
> have dive profiles for 205 dives in it and rest is without...

Yes, quite a few dive computers do that. They keep the key data (start time, 
duration, depth) for a lot of dives, but the profile samples only for NN dives 
(either a hard number or more typically just based on the number of samples 
they can store). IIRC for the OSTC the sample interval impacts how many dives 
with profile it can store. If you do 2 seconds (or whatever the most high-res 
setting is) then it was only a few dozen dives...

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Miika Turkia 
On Fri, Jul 13, 2018 at 1:45 AM, Linus Torvalds <
torva...@linux-foundation.org> wrote:

> On Thu, Jul 12, 2018 at 3:16 PM Anton Lundin  wrote:
> >
> > I just dug up my Sport and put a battery in it and it fails to to
> > download, Both on linux and on Android. I tested it via rfcomm and that
> > worked just fine.
>
> So this actually would mesh with the delay being the issue.
>
> If you use /dev/rfcomm and just open it as a regular serial device,
> then you use the src/serial_posix.c code, and dc_iostream_sleep() will
> call dc_serial_sleep().
>
> Which does the nanosleep that it always used to do, and that we never
> used to override.
>
> The new libdivecomputer "iostream" model made everybody have to
> implement their own sleep implementation, which was obviously not a
> great idea. Not even libdivecomputer got it right (ie the socket sleep
> bug on OS X).
>
> So the "works with rfcomm, doesn't work with direct bluetooth socket"
> would be explained by that sleep difference.
>
> And it also would explain why it just randomly works for some people
> regardless, since it's all just random timing anyway.
>
> But it would be great if somebody could test that patch. None of the
> dive computers I have care (and most of them don't have a front end
> that does any delays in the first place).
>

Hooray, this seems to work. First test was with no new dives and the
connection worked immediately. Then I started a new log, first DL failed,
but a retry started the download. Not sure what went wrong in the failed
attempt, but it did take some time before the attempt timed out.

BTW I do also have the old model with red buttons and classic only.

But, as I downloaded everything that is available on the OSTC sport, it
seems that the oldest dives do not have the dive profile. Does the sport
keep the max depth and time information on log when it needs to start
overwriting? I have dive profiles for 205 dives in it and rest is without...

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Linus Torvalds 
On Thu, Jul 12, 2018 at 3:16 PM Anton Lundin  wrote:
>
> I just dug up my Sport and put a battery in it and it fails to to
> download, Both on linux and on Android. I tested it via rfcomm and that
> worked just fine.

So this actually would mesh with the delay being the issue.

If you use /dev/rfcomm and just open it as a regular serial device,
then you use the src/serial_posix.c code, and dc_iostream_sleep() will
call dc_serial_sleep().

Which does the nanosleep that it always used to do, and that we never
used to override.

The new libdivecomputer "iostream" model made everybody have to
implement their own sleep implementation, which was obviously not a
great idea. Not even libdivecomputer got it right (ie the socket sleep
bug on OS X).

So the "works with rfcomm, doesn't work with direct bluetooth socket"
would be explained by that sleep difference.

And it also would explain why it just randomly works for some people
regardless, since it's all just random timing anyway.

But it would be great if somebody could test that patch. None of the
dive computers I have care (and most of them don't have a front end
that does any delays in the first place).

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Linus Torvalds 
[ I notice that I lost the subsurface list, because Miika just sent
the strace to me in private. So when I replied with a test patch, it
only went to Miika and Dirk ]

On Thu, Jul 12, 2018 at 1:31 PM Linus Torvalds
 wrote:
>
> So considering that this clearly works for *some* people, maybe it's
> literally some timing issue.

.. and looking around in libdivecomputer history, this *used* do be
dc_serial_sleep(), and that just did a nanosleep() internally - and we
never overrode it in our custom serial implementation, because why
would we?

So as libdivecomputer switched "dc_serial_sleep()" to
"dc_iostream_sleep()", we subtly lost the sleep entirely unless the
custom IO implemented it.

In other words, my test patch looks like it really could be very
relevant. Any divecomputer that actually depended on the delay
suddenly got none.

So here's the patch attached again, this time for the whole list in
case somebody else can test it too (eg Anton).

Still entirely untested, but it *did* compile at least once by pure
luck. And this time I added the ftdi case too - which also didn't have
the actual sleep callback, although it did implement the function.

So this could have affected ftdi in addition to bluetooth.

   Linus
 core/qtserialbluetooth.cpp | 11 +--
 core/serial_ftdi.c |  8 +---
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/core/qtserialbluetooth.cpp b/core/qtserialbluetooth.cpp
index 0d3e798cf..93c12c59d 100644
--- a/core/qtserialbluetooth.cpp
+++ b/core/qtserialbluetooth.cpp
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -367,6 +368,12 @@ static dc_status_t qt_serial_set_timeout(void *io, int timeout)
 	return DC_STATUS_SUCCESS;
 }
 
+static dc_status_t qt_custom_sleep(void *io, unsigned int timeout)
+{
+	QThread::msleep(timeout);
+	return DC_STATUS_SUCCESS;
+}
+
 #ifdef BLE_SUPPORT
 dc_status_t
 ble_packet_open(dc_iostream_t **iostream, dc_context_t *context, const char* devaddr, void *userdata)
@@ -387,7 +394,7 @@ ble_packet_open(dc_iostream_t **iostream, dc_context_t *context, const char* dev
 		qt_ble_write, /* write */
 		NULL, /* flush */
 		NULL, /* purge */
-		NULL, /* sleep */
+		qt_custom_sleep, /* sleep */
 		qt_ble_close, /* close */
 	};
 
@@ -420,7 +427,7 @@ rfcomm_stream_open(dc_iostream_t **iostream, dc_context_t *context, const char*
 		qt_serial_write, /* write */
 		NULL, /* flush */
 		qt_serial_purge, /* purge */
-		NULL, /* sleep */
+		qt_custom_sleep, /* sleep */
 		qt_serial_close, /* close */
 	};
 
diff --git a/core/serial_ftdi.c b/core/serial_ftdi.c
index 6d99672f2..9bcf7aba0 100644
--- a/core/serial_ftdi.c
+++ b/core/serial_ftdi.c
@@ -98,12 +98,14 @@ static dc_status_t serial_ftdi_get_transmitted (ftdi_serial_t *device)
 	return DC_STATUS_UNSUPPORTED;
 }
 
-static dc_status_t serial_ftdi_sleep (ftdi_serial_t *device, unsigned long timeout)
+static dc_status_t serial_ftdi_sleep (void *io, unsigned int timeout)
 {
+	ftdi_serial_t *device = io;
+
 	if (device == NULL)
 		return DC_STATUS_INVALIDARGS;
 
-	INFO (device->context, "Sleep: value=%lu", timeout);
+	INFO (device->context, "Sleep: value=%u", timeout);
 
 	struct timespec ts;
 	ts.tv_sec  = (timeout / 1000);
@@ -541,7 +543,7 @@ dc_status_t ftdi_open(dc_iostream_t **iostream, dc_context_t *context)
 		serial_ftdi_write, /* write */
 		NULL, /* flush */
 		serial_ftdi_purge, /* purge */
-		NULL, /* sleep */
+		serial_ftdi_sleep, /* sleep */
 		serial_ftdi_close, /* close */
 	};
 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Anton Lundin 
On 12 July, 2018 - Miika Turkia wrote:

> On Thu, Jul 12, 2018 at 11:03 PM, Dirk Hohndel  wrote:
> 
> >
> > On Jul 12, 2018, at 12:45 PM, Robert Helling  wrote:
> >
> > Hi,
> >
> > On 12. Jul 2018, at 21:26, Miika Turkia  wrote:
> >
> > I did test this with Win10 the other day and it did not work. (Subsurface
> > 4.8.0)
> >
> >
> > I just had a conversation with a user on facebook (who had other problems)
> > who happily downloads dives from OSTC sport on Win 10 to subsurface 4.8.0.
> >
> >
> > That's interesting.
> > Miika, do you also have an OSTC Sport? Or a different model?
> >
> 
> OSTC Sport with FW v10.44. Just updated a few days ago to see if it would
> help...

I just dug up my Sport and put a battery in it and it fails to to
download, Both on linux and on Android. I tested it via rfcomm and that
worked just fine.

My Sport is the old one with the red buttons and the Classic only bt
chip. I'm guessing the Classic only chip is the difference between those
who works and not.


I'm just way to tired to do any sane debugging right now, but I can at
least reproduce it.



Btw, my kernel went belly up when fiddeling with rfcomm:

WARNING: CPU: 2 PID: 11079 at 
/build/linux-hL8lyP/linux-4.15.0/drivers/tty/tty_port.c:257 
tty_port_destructor+0x6c/0x80
Workqueue: events release_one_tty
Call Trace:
 tty_port_put+0x2c/0x30
 rfcomm_tty_cleanup+0x62/0x70 [rfcomm]
 release_one_tty+0x3e/0xc0
 process_one_work+0x1de/0x410
 worker_thread+0x32/0x410
 kthread+0x121/0x140
 ? process_one_work+0x410/0x410
 ? kthread_create_worker_on_cpu+0x70/0x70
 ? do_syscall_64+0x73/0x130
 ? SyS_exit+0x17/0x20
 ret_from_fork+0x35/0x40

You know its time to go to bed when those things happens.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Miika Turkia 
On Thu, Jul 12, 2018 at 11:03 PM, Dirk Hohndel  wrote:

>
> On Jul 12, 2018, at 12:45 PM, Robert Helling  wrote:
>
> Hi,
>
> On 12. Jul 2018, at 21:26, Miika Turkia  wrote:
>
> I did test this with Win10 the other day and it did not work. (Subsurface
> 4.8.0)
>
>
> I just had a conversation with a user on facebook (who had other problems)
> who happily downloads dives from OSTC sport on Win 10 to subsurface 4.8.0.
>
>
> That's interesting.
> Miika, do you also have an OSTC Sport? Or a different model?
>

OSTC Sport with FW v10.44. Just updated a few days ago to see if it would
help...

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Dirk Hohndel 

> On Jul 12, 2018, at 12:45 PM, Robert Helling  wrote:
> 
> Hi,
> 
>> On 12. Jul 2018, at 21:26, Miika Turkia > > wrote:
>> 
>> I did test this with Win10 the other day and it did not work. (Subsurface 
>> 4.8.0)
> 
> I just had a conversation with a user on facebook (who had other problems) 
> who happily downloads dives from OSTC sport on Win 10 to subsurface 4.8.0.

That's interesting.
Miika, do you also have an OSTC Sport? Or a different model?

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Robert Helling 
Hi,

> On 12. Jul 2018, at 21:26, Miika Turkia  wrote:
> 
> I did test this with Win10 the other day and it did not work. (Subsurface 
> 4.8.0)
> 

I just had a conversation with a user on facebook (who had other problems) who 
happily downloads dives from OSTC sport on Win 10 to subsurface 4.8.0.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Linus Torvalds 
On Thu, Jul 12, 2018 at 12:26 PM Miika Turkia  wrote:
>
> I did test this with Win10 the other day and it did not work. (Subsurface 
> 4.8.0)
>
> Just tested Android and it started to download the data.

Can you do a "strace -f -Ttt" under Linux (the resulting trace file
will be *huge* because of all the GUI interactions) and try to find
the point where it starts doing IO?

It should be fairly easy to see in the system call traces, because the
BT open should be something like

socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);

which should be easy-ish to find in the strace mess (strace should be
translating all those symbolic names for SOCK_STREAM and AF_BLUETOOTH
etc).

And once you find the open, the actual IO on that socket should be
visible, and with that "-Ttt" we should see the timings too (ie maybe
we have some similar "give up too early" that the MacOS side has)

 Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Robert Helling 
Hi,

> On 12. Jul 2018, at 20:20, Dirk Hohndel  wrote:
> 
> So that's the merge commit to bring in the upstream code. About the worst one 
> to end up on for the bisect.
> 
> Before I try to spot something by just reading the changes - Linus, any idea 
> how to narrow this down further?
> 

I was a bit worried that when I wrote it works for me with current master that 
might be using an old libdivecomputer version. So I double checked and it also 
works for the official version 4.8.0 from the server.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Miika Turkia 
On Thu, Jul 12, 2018 at 10:15 PM, Linus Torvalds <
torva...@linux-foundation.org> wrote:

> On Thu, Jul 12, 2018 at 11:52 AM Miika Turkia 
> wrote:
> >
> > The broken one fails without any success. Console output:
>
> Yeah, it's the actual IO log I was hoping would show something, but it
> just says
>
>   INFO: Purge: direction=3
>   INFO: Write: size=4, data=AAABCDEF
>   INFO: Sleep: value=100
>   INFO: Read: size=0, data=
>   ERROR: Failed to verify echo. [in ../../src/hw_ostc3.c:457
> (hw_ostc3_device_init_service)]
>
> so that's not very helpful - it just looks like *no* io works.
>
> Which is odd, since apparently it works for other people (at least on
> mac), and nothing at all in any of this is mac-specific. So we know
> the custom IO stuff is hooked up right - the Linux code even uses
> exactly the same stuff as OS X (now, Android or Windows would be
> different, but OS X and Linux share the exact same code on the
> bluetooth side).
>
> No ideas where to even start debugging this right now.


I did test this with Win10 the other day and it did not work. (Subsurface
4.8.0)

Just tested Android and it started to download the data.

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Linus Torvalds 
On Thu, Jul 12, 2018 at 11:52 AM Miika Turkia  wrote:
>
> The broken one fails without any success. Console output:

Yeah, it's the actual IO log I was hoping would show something, but it just says

  INFO: Purge: direction=3
  INFO: Write: size=4, data=AAABCDEF
  INFO: Sleep: value=100
  INFO: Read: size=0, data=
  ERROR: Failed to verify echo. [in ../../src/hw_ostc3.c:457
(hw_ostc3_device_init_service)]

so that's not very helpful - it just looks like *no* io works.

Which is odd, since apparently it works for other people (at least on
mac), and nothing at all in any of this is mac-specific. So we know
the custom IO stuff is hooked up right - the Linux code even uses
exactly the same stuff as OS X (now, Android or Windows would be
different, but OS X and Linux share the exact same code on the
bluetooth side).

No ideas where to even start debugging this right now.

Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Miika Turkia 
On Thu, Jul 12, 2018 at 9:22 PM, Linus Torvalds <
torva...@linux-foundation.org> wrote:

> On Thu, Jul 12, 2018 at 11:13 AM Miika Turkia 
> wrote:
> >
> > Commit 8a34d822ff5b6b235434f4a240f2f559ef331503 (libdivecomputer) seems
> to break the BT download from OSTC for me.
>
> Ouch.
>
> That's the "switch over to libdivecomputer iostream" commit.
>
> Which is about the worst possible commit to test, because that's when
> the whole IO world just switched over.
>
> Can you do a libdivecomputer dump-file for the works case just before
> that, and a failing one.
>
> At least we'd see the IO patterns as libdivecomputer sees them.
>

The broken one fails without any success. Console output:
---8<---
Starting download from  BT
Starting the thread 0
INFO: FTDI disabled
INFO: dc_deveice_open error value of 0
Finishing the thread Dive data import error dives downloaded 0
---8<---

And attached is the little available on the log.

miika
Subsurface: v4.4.1-281-g86ac7fdf4714, built with libdivecomputer v0.7.0-devel-Subsurface-branch (8a34d822ff5b6b235434f4a240f2f559ef331503)
INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, flowcontrol=0
INFO: Timeout: value=3000
INFO: Sleep: value=300
INFO: Purge: direction=3
INFO: Write: size=4, data=AAABCDEF
INFO: Sleep: value=100
INFO: Read: size=0, data=
ERROR: Failed to verify echo. [in ../../src/hw_ostc3.c:457 (hw_ostc3_device_init_service)]
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Linus Torvalds 
On Thu, Jul 12, 2018 at 11:13 AM Miika Turkia  wrote:
>
> Commit 8a34d822ff5b6b235434f4a240f2f559ef331503 (libdivecomputer) seems to 
> break the BT download from OSTC for me.

Ouch.

That's the "switch over to libdivecomputer iostream" commit.

Which is about the worst possible commit to test, because that's when
the whole IO world just switched over.

Can you do a libdivecomputer dump-file for the works case just before
that, and a failing one.

At least we'd see the IO patterns as libdivecomputer sees them.

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Dirk Hohndel 

> On Jul 12, 2018, at 11:13 AM, Miika Turkia  wrote:
>  
>  I can confirm, with current master, download from OSTC Sport to my Mac 
>  works both for classic as well as Bluetooth LE.
> >>> 
> >>> what os? Can you test the appimage on linux?
> >> 
> >> Does it work with a locally compiled from source version? Or is that 
> >> broken, too?
> > 
> > self compiled is also broken for me. Before Dec 4 (ish) works but anything 
> > after does not. 
> 
> So it works on Mac. Jan, are you using it on Linux or also on a Mac?
> I don't have an OSTC, so this isn't something I can help bisect...
> 
> Commit 8a34d822ff5b6b235434f4a240f2f559ef331503 (libdivecomputer) seems to 
> break the BT download from OSTC for me.

So that's the merge commit to bring in the upstream code. About the worst one 
to end up on for the bisect.

Before I try to spot something by just reading the changes - Linus, any idea 
how to narrow this down further?

Thanks

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Miika Turkia 
On Thu, Jul 12, 2018 at 8:11 PM, Dirk Hohndel  wrote:

>
> > On Jul 12, 2018, at 8:44 AM, Miika Turkia 
> wrote:
> >
> > But I thought that both Jan and Robert had reported success
> downloading from their OSTC just recently.
> 
>  I can confirm, with current master, download from OSTC Sport to my
> Mac works both for classic as well as Bluetooth LE.
> >>>
> >>> what os? Can you test the appimage on linux?
> >>
> >> Does it work with a locally compiled from source version? Or is that
> broken, too?
> >
> > self compiled is also broken for me. Before Dec 4 (ish) works but
> anything after does not.
>
> So it works on Mac. Jan, are you using it on Linux or also on a Mac?
> I don't have an OSTC, so this isn't something I can help bisect...
>

Commit 8a34d822ff5b6b235434f4a240f2f559ef331503 (libdivecomputer) seems to
break the BT download from OSTC for me.

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Dirk Hohndel 

> On Jul 12, 2018, at 8:44 AM, Miika Turkia  wrote:
> 
> But I thought that both Jan and Robert had reported success downloading 
> from their OSTC just recently.
 
 I can confirm, with current master, download from OSTC Sport to my Mac 
 works both for classic as well as Bluetooth LE.
>>> 
>>> what os? Can you test the appimage on linux?
>> 
>> Does it work with a locally compiled from source version? Or is that broken, 
>> too?
> 
> self compiled is also broken for me. Before Dec 4 (ish) works but anything 
> after does not. 

So it works on Mac. Jan, are you using it on Linux or also on a Mac?
I don't have an OSTC, so this isn't something I can help bisect...

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Miika Turkia 


> On 12 Jul 2018, at 17.46, Dirk Hohndel  wrote:
> 
> 
>>> On Jul 12, 2018, at 2:55 AM, Miika Turkia  wrote:
>>> 
 On 12. Jul 2018, at 06:24, Dirk Hohndel  wrote:
 
 But I thought that both Jan and Robert had reported success downloading 
 from their OSTC just recently.
>>> 
>>> I can confirm, with current master, download from OSTC Sport to my Mac 
>>> works both for classic as well as Bluetooth LE.
>> 
>> what os? Can you test the appimage on linux?
> 
> Does it work with a locally compiled from source version? Or is that broken, 
> too?

self compiled is also broken for me. Before Dec 4 (ish) works but anything 
after does not. 

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Dirk Hohndel 

> On Jul 12, 2018, at 2:55 AM, Miika Turkia  wrote:
>> 
>>> On 12. Jul 2018, at 06:24, Dirk Hohndel  wrote:
>>> 
>>> But I thought that both Jan and Robert had reported success downloading 
>>> from their OSTC just recently.
>> 
>> I can confirm, with current master, download from OSTC Sport to my Mac works 
>> both for classic as well as Bluetooth LE.
> 
> what os? Can you test the appimage on linux?

Does it work with a locally compiled from source version? Or is that broken, 
too?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-12 Thread Miika Turkia 


> On 12 Jul 2018, at 12.48, Robert Helling  wrote:
> 
> Hi,
> 
>> On 12. Jul 2018, at 06:24, Dirk Hohndel  wrote:
>> 
>> But I thought that both Jan and Robert had reported success downloading from 
>> their OSTC just recently.
> 
> I can confirm, with current master, download from OSTC Sport to my Mac works 
> both for classic as well as Bluetooth LE.

what os? Can you test the appimage on linux?

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-11 Thread Dirk Hohndel 

> On Jul 11, 2018, at 9:14 PM, Miika Turkia  wrote:
> 
> On Thu, Jul 12, 2018 at 12:46 AM, Dirk Hohndel  > wrote:
> 
> Just a heads up - I want to release 4.8.1 fairly soon. Mainly to deal with 
> the issues with Mac (where I had to embarrassingly push a new installer a 
> couple days after release which is something that I hate doing in the first 
> place). Anyway, the problems in the Mac binary are resolved now, and we even 
> have a few new features as indicated by the CHANGELOG...
> 
> What I'm not sure about is what the best way is to do a cut off. Are we at a 
> good spot right now? Are there a few more PRs that should go in? Or are there 
> commits that are in that would be better if they weren't in 4.8.1?
> 
> Well, it would be great if BT download from OSTC Sport was working. At least 
> it has been broken for me for quite a long time. I have no idea of what is 
> wrong, but it just does not work. I gotta use 
> Subsurface-6addfe166-x86_64.AppImage to get the data out. IIRC at some point 
> I bisected it to have broken down between 
> 54f6bff9290906a62628c85e1adb3a74ca487722 and 
> 8ae735a4d70307ebe2a42d315697f02ce71dbe88. But digging into this area is quite 
> challenging since the interfaces change  and one has to switch versions of 
> both Subsurface and libdivecomputer while bisecting.
> 
> IIRC Jeff mentioned at some point that he had fixed OSTC bug on 
> libdivecomputer, but at least latest latest continuous build (AppImage) is 
> not working for me and the fix should be already in Subsurface. Is BT 
> download from OSTC working for someone on latest release or devel version?

I don't have an OSTC with BT for testing. But I thought that both Jan and 
Robert had reported success downloading from their OSTC just recently.
Bisecting across that merge is insanely painful - I agree. I wish I had a 
better idea of how to approach this :-(
Without hardware to test things with, I really don't know what else I could do.

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 4.8.1 planning

2018-07-11 Thread Miika Turkia 
On Thu, Jul 12, 2018 at 12:46 AM, Dirk Hohndel  wrote:

>
> Just a heads up - I want to release 4.8.1 fairly soon. Mainly to deal with
> the issues with Mac (where I had to embarrassingly push a new installer a
> couple days after release which is something that I hate doing in the first
> place). Anyway, the problems in the Mac binary are resolved now, and we
> even have a few new features as indicated by the CHANGELOG...
>
> What I'm not sure about is what the best way is to do a cut off. Are we at
> a good spot right now? Are there a few more PRs that should go in? Or are
> there commits that are in that would be better if they weren't in 4.8.1?
>

Well, it would be great if BT download from OSTC Sport was working. At
least it has been broken for me for quite a long time. I have no idea of
what is wrong, but it just does not work. I gotta use
Subsurface-6addfe166-x86_64.AppImage to get the data out. IIRC at some
point I bisected it to have broken down between
54f6bff9290906a62628c85e1adb3a74ca487722 and
8ae735a4d70307ebe2a42d315697f02ce71dbe88.
But digging into this area is quite challenging since the interfaces
change  and one has to switch versions of both Subsurface and
libdivecomputer while bisecting.

IIRC Jeff mentioned at some point that he had fixed OSTC bug on
libdivecomputer, but at least latest latest continuous build (AppImage) is
not working for me and the fix should be already in Subsurface. Is BT
download from OSTC working for someone on latest release or devel version?

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface