Re: Travis now build-checks iOS

[Anton Lundin]

On 24 April, 2018 - Dirk Hohndel wrote:

> This was the one missing platform, I finally beat it into submission.
> It’s only compiling for the simulator (because for insane reasons you have to 
> have a signing key available in order to build for device), but that should 
> be sufficient to ensure that we don’t break the build…

Good work!

CI for the win.


Now we just need to start adding some functional tests, besides "it
compiles" =)


//Anton


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

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

> On Apr 24, 2018, at 6:04 PM, Dirk Hohndel  wrote:
> 
> 
>> On Apr 24, 2018, at 5:59 PM, Dirk Hohndel  wrote:
>>> 
>>> Oh, and I realized that I should also mention that I didn't apply your
>>> fixes. I (obviously) had no test coverage for them, but they all
>>> looked fine.
>>> 
>>> So you'll need to cherry pick or rebase your transport patches and the
>>> Android stuff. My rebased branch was the same old contents, just
>>> cleaned up.
> 
> Actually, the removal of the old BLE code made the Android patch unnecessary.

And what I meant to say was “almost makes it unnecessary”. Arg.
I LOVE TRAVIS.

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

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Linus Torvalds]

On Tue, Apr 24, 2018 at 5:43 PM, Linus Torvalds
 wrote:
> NOTE! I have *not* updated the 'libdivecomputer' subproject in the
> subsurface repository to point to that version of libdivecomputer. I
> still build them as separate projects, and particularly when I was
> rebasing, I didn't want to tie them together. I was thinking you'd do
> that.

Oh, and I realized that I should also mention that I didn't apply your
fixes. I (obviously) had no test coverage for them, but they all
looked fine.

So you'll need to cherry pick or rebase your transport patches and the
Android stuff. My rebased branch was the same old contents, just
cleaned up.

I assume that was all obvious, but I though maybe better just make it explicit.

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

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

> On Apr 24, 2018, at 5:43 PM, Linus Torvalds  
> wrote:
> 
> On Tue, Apr 24, 2018 at 5:11 PM, Dirk Hohndel  wrote:
>>> 
>>> Dirk - up to you. And obviously, I don't know when you want to cut
>>> over to the new libdivecomputer world order.
>> 
>> I’m happy to do it now - but for libdivecomputer I’m always a bit
>> gun shy, so I’d prefer that you did the rebasing and just pointed
>> me to a tree that you want me to start with (as this is a new branch).
> 
> Ok, I've rebased the Subsurface-NG branch in my git repo on top of
> Jef's current branch, so now that branch has the OSTC3 fix:
> 
>git://github.com/torvalds/libdc-for-dirk.git Subsurface-NG

Thanks - so we’ll stick with Subsurface-NG as branch name? :-)

> NOTE! I have *not* updated the 'libdivecomputer' subproject in the
> subsurface repository to point to that version of libdivecomputer. I
> still build them as separate projects, and particularly when I was
> rebasing, I didn't want to tie them together. I was thinking you'd do
> that.

Yes, that’s easy. I’ll do that.

Thanks

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

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Linus Torvalds]

On Tue, Apr 24, 2018 at 5:11 PM, Dirk Hohndel  wrote:
>>
>> Dirk - up to you. And obviously, I don't know when you want to cut
>> over to the new libdivecomputer world order.
>
> I’m happy to do it now - but for libdivecomputer I’m always a bit
> gun shy, so I’d prefer that you did the rebasing and just pointed
> me to a tree that you want me to start with (as this is a new branch).

Ok, I've rebased the Subsurface-NG branch in my git repo on top of
Jef's current branch, so now that branch has the OSTC3 fix:

git://github.com/torvalds/libdc-for-dirk.git Subsurface-NG

NOTE! I have *not* updated the 'libdivecomputer' subproject in the
subsurface repository to point to that version of libdivecomputer. I
still build them as separate projects, and particularly when I was
rebasing, I didn't want to tie them together. I was thinking you'd do
that.

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

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

> On Apr 24, 2018, at 12:53 PM, Linus Torvalds  
> wrote:
> 
> Ok, I finally got around to cleaning up my subsurface changes, and
> there is now a newly rebased libdivecomputer-NG branch at
> 
>   git://github.com/torvalds/subsurface-for-dirk.git libdivecomputer-NG

Excellent - I’ve been waiting for that. I’m running  out of time today, but 
I’ll work on this tomorrow.

> that I think is in good enough shape to be pulled.
> 
> That branch has the same requirement on the "Subsurface-NG" branch in
> libdivecomputer, but has additionally:
> 
> - many cleanups, including entirely removing the "ble_serial" code
> (which in the old branch stayed around as dead code)
> 
>   The ble_serial code wrapped the BLE code in a serial emulation
> layer, but now that libdivecomputer natively knows about BLE, there's
> no point any more.
> 
> - simplified history.
> 
>   I couldn't really split things up into lots of small changes (since
> it's a flag-day for the new libdivecomputer interface anyway), and
> instead the conversion history is just two commits: (a) convert our
> custom IO implementation to the new libdivecomputer world order and
> (b) hook it all in and use the new world order.
> 
> - I added the fingerprint patch.
> 
>   Ok, so this has nothing to do with the new world order, and maybe
> Dirk wants to handle this some other way, but it was part of my
> testing and seems solid, and is technically about libdivecomputer (and
> affects nothing else).

I think that last iteration made sense. I haven’t thought it through for
all the different OSs to make sure it works, but given that you used
a standard path, it should.

> NOTE! I have *not* updated libdivecomputer itself. I looked at it, and
> it all looks fine. I think Dirk should just use his "NG-test" branch
> as-is (ie my NG update and merging in the libdivecomputer upstream
> bugfix). But just rebasing it on top of the libdivecomputer OSTC3
> bugfix would be fine too. But unlike the subsurface branch, there's
> not really any big *reason* to rebase.
> 
> Dirk - up to you. And obviously, I don't know when you want to cut
> over to the new libdivecomputer world order.

I’m happy to do it now - but for libdivecomputer I’m always a bit
gun shy, so I’d prefer that you did the rebasing and just pointed
me to a tree that you want me to start with (as this is a new branch).

Thanks

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

Fwd: Re: Any brave dive computer download testers out there?

[Willem Ferguson]

On 24/04/2018 20:08, Linus Torvalds wrote:

On Tue, Apr 24, 2018 at 11:03 AM, Willem Ferguson
 wrote:

Initial handshaking took maybe 40s, showing error message in red bar at
bottom of screen "Timeout"

Hmm. It looks like it first tried to do a BLE download, and that
failed (and this is what took a longish time).

And then because of the failure, it fell back on old-style BT rfcomm, and:


But, if not interrupted, the download proceeded perfectly shortly after the
timeout message and download exited normally on the GUI.

.. apparently rfcomm works for you and the fallback was successful.

Has BLE ever worked for you?


NOPE

I did the same download by setting the dropdown option in the BT setup
panel to 'Force Classical'. Took about 25 sec to do handshaking, still
getting "Timeout while trying to connect". Does not appear to make
difference and successful end result is same as previously, downloading
all my dives. Interesting error message at end of log. I have never
managed to get the BLE working. My Petrel is pretty recent, so I am
reasonably sure it can do both. But the user manual and the Shearwater
website does not provide any insight into this.

Desktop$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
can't find Subsurface localization for locale "en-ZA"
Missing CAP_NET_ADMIN permission. Cannot determine whether a found
address is of random or public type.
Starting download from  BT
Starting the thread 0
Enabling GATT request timeout behavior 2
qt_ble_open( 00:13:43:5B:8F:BE )
Creating default GAP/GATT services
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:5B:8F:BE
void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Resource
temporarily unavailable"
Connection on channel 1 failed. Trying on channel number 5.
INFO: dc_device_open error value of 0
[39.400513] ERROR: Failed to download the dive. [in
../../src/shearwater_petrel.c:330 (shearwater_petrel_device_foreach)]
Finishing the thread Dive data import error dives downloaded 9

Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

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

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

On Tue, Apr 24, 2018 at 11:25 AM, Willem Ferguson
 wrote:
>
> I did the same download by setting the dropdown option in the BT setup panel
> to 'Force Classical'.

The new code just ignores the classic/ble/auto setting right now.

I'd rather do it using the "dc_transports" model that we now use for
everything else anyway, the old model was totally different.

> Interesting error message at end of log. I have never managed to get the BLE
> working. My Petrel is pretty recent, so I am reasonably sure it can do both.

The Shearwater dive computers can be temperamental when it comes to BLE.

I've never used the rfcomm thing (my Perdix AI doesn't support it),
but the BLE works reliably for me - once it has connected once. But
getting it to connect that first time can be a crap-shoot.

So the Shearwater BLE code seems to have some history, and probably
remembers who it paired with last or something. And apparently you
have never been able to get it to get to that paired state.

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

Re: Any brave dive computer download testers out there?

[Willem Ferguson]

On 24/04/2018 20:08, Linus Torvalds wrote:

On Tue, Apr 24, 2018 at 11:03 AM, Willem Ferguson
 wrote:

Initial handshaking took maybe 40s, showing error message in red bar at
bottom of screen "Timeout"

Hmm. It looks like it first tried to do a BLE download, and that
failed (and this is what took a longish time).

And then because of the failure, it fell back on old-style BT rfcomm, and:


But, if not interrupted, the download proceeded perfectly shortly after the
timeout message and download exited normally on the GUI.

.. apparently rfcomm works for you and the fallback was successful.

Has BLE ever worked for you?


NOPE

I did the same download by setting the dropdown option in the BT setup 
panel to 'Force Classical'. Took about 25 sec to do handshaking, still 
getting "Timeout while trying to connect". Does not appear to make 
difference and successful end result is same as previously, downloading 
all my dives. Interesting error message at end of log. I have never 
managed to get the BLE working. My Petrel is pretty recent, so I am 
reasonably sure it can do both. But the user manual and the Shearwater 
website does not provide any insight into this.


Desktop$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
can't find Subsurface localization for locale "en-ZA"
Missing CAP_NET_ADMIN permission. Cannot determine whether a found 
address is of random or public type.

Starting download from  BT
Starting the thread 0
Enabling GATT request timeout behavior 2
qt_ble_open( 00:13:43:5B:8F:BE )
Creating default GAP/GATT services
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:5B:8F:BE
void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Resource 
temporarily unavailable"

Connection on channel 1 failed. Trying on channel number 5.
INFO: dc_device_open error value of 0
[39.400513] ERROR: Failed to download the dive. [in 
../../src/shearwater_petrel.c:330 (shearwater_petrel_device_foreach)]

Finishing the thread Dive data import error dives downloaded 9

Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

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

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

On Tue, Apr 24, 2018 at 11:03 AM, Willem Ferguson
 wrote:
>
> Initial handshaking took maybe 40s, showing error message in red bar at
> bottom of screen "Timeout"

Hmm. It looks like it first tried to do a BLE download, and that
failed (and this is what took a longish time).

And then because of the failure, it fell back on old-style BT rfcomm, and:

> But, if not interrupted, the download proceeded perfectly shortly after the
> timeout message and download exited normally on the GUI.

.. apparently rfcomm works for you and the fallback was successful.

Has BLE ever worked for you?

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

Re: Any brave dive computer download testers out there?

[Willem Ferguson]

I thought I should attach the log of my BT download from a Petrel 2.

Initial handshaking took maybe 40s, showing error message in red bar at 
bottom of screen "Timeout"


But, if not interrupted, the download proceeded perfectly shortly after 
the timeout message and download exited normally on the GUI.


Desktop$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
Starting download from  BT
Starting the thread 0
Bluez 5 detected.
Enabling GATT request timeout behavior 2
qt_ble_open( 00:13:43:5B:8F:BE )
Creating default GAP/GATT services
Missing CAP_NET_ADMIN permission. Cannot determine whether a found 
address is of random or public type.

addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:5B:8F:BE
void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Resource 
temporarily unavailable"

Connection on channel 1 failed. Trying on channel number 5.
INFO: dc_device_open error value of 0
Finishing the thread  dives downloaded 11

Kind regards,

willem





--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

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

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

On Tue, Apr 24, 2018 at 5:27 AM, Sébastien Dugué
 wrote:
> On Mon, Apr 23, 2018 at 7:07 PM, Linus Torvalds 
>  wrote:
>>
>> On most dive computers, it's 4 bytes, on others it's 5-6, and on some
>> it's 16 bytes of random binary data.
>
>   My bad, I assumed that feature was only present in the Uwatec DCs where it's
> a timestamp.
>
>   And I cannot imagine how something else might be useful for that purpose...

Well, the fingerprint can anything, which is part of the problem. It
can be an offset into the dive computer buffer. It could be just an
index into the dive computer dive table. It could be the first few
bytes of the dive download that contains the unparsed dive data (which
probably *includes* the dive date, but can have a internal dive
computer dive number)

So in practice it really is random data, and it's not useful to
subsurface directly. We actually do use it to generate a "dive ID"
(that is used to check for duplicates), but that is a fairly simple
and well-defined thing (it's the first four bytes of a SHA1 hash -
either of the fingerprint data, or if the dive computer gives a
particular "Dive ID" string.

And I *really* don't want to save it to our dive logs, because it's
not useful long-term. It's not useful to a user, but it's not even
useful to subsurface long term - only the last dive matters. So saving
it for every dive is fundamentally wrong - it's not how it would ever
be used.

But I think I've come up with an approach that is viable, exactly
*because* we do have a dive ID anyway. We can save the fingerprint
*and* the dive ID in the cache file, and then when we *use* the
fingerprint, we just verify that we have a dive that matches the dive
ID associated with that fingerprint.

So at worst, we'll never use the fingerprint at all, because the last
time somebody did a download, they didn't save the dives (or maybe
they just did't save them into the file we're now using, or didn't
save the *last* dive or whatever).

But then we're no worse off than we are now.

And if we *do* have the dive that is associated with the fingerprint,
then we'll use it, and only download new dives up until that point.

The attached patch seems to work in my (very limited!) testing.

Testers welcome. It should apply fine to any modern subsurface tree
(ie you don't have to have the "NG" branch, but it won't hurt, and
it's what I tested and used as a base).

Linus
 core/libdivecomputer.c | 146 +
 core/libdivecomputer.h |   2 +
 2 files changed, 148 insertions(+)

diff --git a/core/libdivecomputer.c b/core/libdivecomputer.c
index c547a85b2..990904878 100644
--- a/core/libdivecomputer.c
+++ b/core/libdivecomputer.c
@@ -8,6 +8,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include "gettext.h"
 #include "dive.h"
 #include "device.h"
@@ -21,6 +24,9 @@
 
 #include "libdivecomputer.h"
 #include "core/version.h"
+#include "core/qthelper.h"
+#include "core/membuffer.h"
+#include "core/file.h"
 
 //
 // If we have an old libdivecomputer, it doesn't
@@ -785,6 +791,16 @@ static int dive_cb(const unsigned char *data, unsigned int size,
 	dive->dc.model = strdup(devdata->model);
 	dive->dc.diveid = calculate_diveid(fingerprint, fsize);
 
+	/* Should we add it to the cached fingerprint file? */
+	if (fingerprint && fsize && !devdata->fingerprint) {
+		devdata->fingerprint = calloc(fsize, 1);
+		if (devdata->fingerprint) {
+			devdata->fsize = fsize;
+			devdata->fdiveid = dive->dc.diveid;
+			memcpy(devdata->fingerprint, fingerprint, fsize);
+		}
+	}
+
 	// Parse the dive's header data
 	rc = libdc_header_parser (parser, devdata, dive);
 	if (rc != DC_STATUS_SUCCESS) {
@@ -924,6 +940,121 @@ static unsigned int fixup_suunto_versions(device_data_t *devdata, const dc_event
 
 	return serial;
 }
+#ifndef O_BINARY
+  #define O_BINARY 0
+#endif
+static void do_save_fingerprint(device_data_t *devdata, const char *tmp, const char *final)
+{
+	int fd, written = -1;
+
+	fd = subsurface_open(tmp, O_WRONLY | O_BINARY | O_CREAT | O_TRUNC, 0666);
+	if (fd < 0)
+		return;
+
+	/* The fingerprint itself.. */
+	written = write(fd, devdata->fingerprint, devdata->fsize);
+
+	/* ..followed by the dive ID of the fingerprinted dive */
+	if (write(fd, >fdiveid, 4) != 4)
+		written = -1;
+
+	/* I'd like to do fsync() here too, but does Windows support it? */
+	if (close(fd) < 0)
+		written = -1;
+
+	if (written == devdata->fsize) {
+		if (!subsurface_rename(tmp, final))
+			return;
+	}
+	unlink(tmp);
+}
+
+/*
+ * Save the fingerprint after a successful download
+ */
+static void save_fingerprint(device_data_t *devdata)
+{
+	char *dir, *tmp, *final;
+
+	if (!devdata->fingerprint)
+		return;
+
+	dir = format_string("%s/fingerprints", system_default_directory());
+	subsurface_mkdir(dir);
+	tmp = format_string("%s/%04x.tmp", dir, devdata->deviceid);
+	final = format_string("%s/%04x", dir, 

Re: Any brave dive computer download testers out there?

[Sébastien Dugué]

On Mon, Apr 23, 2018 at 7:07 PM, Linus Torvalds
 wrote:
> On Mon, Apr 23, 2018 at 12:56 AM, Sébastien Dugué
>  wrote:
>> On Sun, Apr 22, 2018 at 10:09 PM, Linus Torvalds
>>  wrote:
>>>
>>> It still has the exact same problem it always had: it's random binary data
>>> that we'd have to encode some way.
>>
>>   Well, it's not so random. It's in fact a timestamp in the DC format which
>> specifies from which dive we wish to download.
>
> I wish that was the case. It's not.
>
> It's a timestamp on _some_ dive computers. On others, it's other random data.
>
> On most dive computers, it's 4 bytes, on others it's 5-6, and on some
> it's 16 bytes of random binary data.

  My bad, I assumed that feature was only present in the Uwatec DCs where it's
a timestamp.

  And I cannot imagine how something else might be useful for that purpose...

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