Re: Bluetooth / BLE failing with Shearwater Petrel 2 on mobile and desktop

[Rick Walsh]

On 23 August 2017 at 20:03, Miika Turkia  wrote:

> On Wed, Aug 23, 2017 at 12:55 PM, Rick Walsh  wrote:
> >
> >
> > On 23 Aug. 2017 19:21, "Anton Lundin"  wrote:
> >
> > On 23 August, 2017 - Rick Walsh wrote:
> >
> >> Hi,
> >>
> > ...
> >
> >> Downloading to my desktop (v4.6.4-737-g5de49401c89c, built with Qt5.7.1
> on
> >> Fedora 26) also fails now.
> >
> >> Does anyone have any clue how to fix this?
> >
> > I don't know if 5.7.1 is modern enough for BT LE stuff on bluez. There's
> > a "// HACK ALERT! Qt 5.9 needs this for proper Bluez operation" and such
> > which points one towards a modern Qt.
> >
> > Test with a newer Qt. Newer is better? What could possibly go wrong?
> >
> > I tried that today. Downloaded qt5.9.1, and used ccmake in
> subsurface/build
> > to point to the right qt directories. But the build fails because it
> doesn't
> > have webkit. Is there some trick to make it work?
> >
> > I downloaded dives succesfully on Windows 7 with the latest binary.
>
> ccmake one more time, and switch to webengine
>

Thanks, I'll try that when I get a chance - hopefully some time in the
coming days.  I really hope I don't have to compile Qt myself.

Any idea why the mobile download might failing using Dirk's apk, and how
this could be debugged?

I'm using my Windows 7 laptop now.  I don't have my dive computer with me,
but going to the download dialog the BT address doesn't have the le:
prefix, so it appears that the successful download was using ordinary BT.

Cheers,

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

Re: Qt 5.9 openssl problems on F26

[Linus Torvalds]

On Aug 23, 2017 13:43, "Thiago Macieira"  wrote:


There's also a licensing component here. One cannot distribute GPLv2-only
software linking to OpenSSL 1.1.


Don't buy into the crazy FSF crap. It's bullshit, and it's just a bedtime
story made up by the FSF to try to push their agenda and try to convince
people that GPLv3 solves some problems.

OpenSSL uses the Apache 2.0 license, and Apache is very clear that they
consider it compatible with GPLv2.

To quote the Apache people from *their* license page:

 "Despite our best efforts, the FSF has never considered the Apache License
to be compatible with GPL version 2, citing the patent termination and
indemnification provisions as restrictions not present in the older GPL
license. The Apache Software Foundation believes that you should always try
to obey the constraints expressed by the copyright holder when
redistributing their work."

That's basically saying that the Apache people are ok with the GPLv2
combination, and they are saying that you should listen to the copyright
holder (which is not the FSF when it comes to subsurface).

It's literally the FSF being crazy (not the first time) and trying to push
their agenda (also not the first time).

Note the " despite our best efforts" language. The Apache people gave up on
the FSF.

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

Re: Qt 5.9 openssl problems on F26

[Thiago Macieira]

On Sunday, 6 August 2017 00:07:30 PDT Dirk Hohndel wrote:
> While I don't even pretend to be a security expert, this is a topic that I
> have quite some familiarity with. Yes, right now OpenSSL 1.0.2 (latest) is
> still considered "as secure" as 1.1.0 latest. I can understand the Qt team
> delaying this migration for 5.10 as it is quite painful.

There's also a licensing component here. One cannot distribute GPLv2-only 
software linking to OpenSSL 1.1.

Subsurface is GPLv2-only, isn't it?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

Re: Statistics

[Tomaz Canabrava]

On Tue, Aug 22, 2017 at 7:01 PM, Davide DB  wrote:

> Despite of huge Tomaz effort (thanks Tomaz) IMHO from usability and
> readability pov this layout is poor. It works only on hi dpi screens.
> Of course stats are better than nothing. So thank you again.
>

I think it actually works for non hidpi screens if we have less columns, I
think the problem here is that I tested against all trips that I have.
I'm working on the Yearly Statistics now and I think it would be easier to
See.



> davide@mobile
>
> On Aug 22, 2017 12:24, "Willem Ferguson" 
> wrote:
>
>> On 21/08/2017 18:18, Tomaz Canabrava wrote:
>>
>>
>> Willem,
>>
>> See if this image is better.
>>
>> Got this, thank you very much. It looks extremely promising: the
>> presentation style looks extremely acceptable.
>>
>> A few questions and comments.
>>
>> Question 1. Beneath each blue bar for Depth and Temperature is a thin
>> (grey?) horizontal line. What does this indicate? For temperature it always
>> corresponds to a value of zero °C. For Depth it corresponds to a value of
>> between 0 and 15.
>>
>> Question 2. The vertical positions of the blue bars in each column, what
>> do they signify? For instance, the leftmost bar for temperature (a trip to
>> Hoodsport) indicates around 45 (°F ?? = ~7 °C??), but the next blue bar (a
>> trip to Maui) indicates 80 (~28 °C ??). Please clarify?(by the way, there
>> is an unlabled bar on the extreme left, to the left of the first Hoodsport
>> trip. Maybe there was a trip to a site where no locality has been
>> defined??). So it may be that the blue vertical bar indicates the minimum
>> and the maximum values for a specific trip?? If so, the values for SAC look
>> realistic if the measurement unit is l/min. The temperatures looks
>> realistic if the measurement unit is °F. The depth values look realistic if
>> the measurement unit is m (except that six dive trips have a minimum dive
>> depth of zero).
>>
>> Comment 1. For this type of graph, it is critical that the calculations
>> are done for a *selected set of dives* (i.e. those that have been selected
>> directly from the dive list or through the filter tool). I see the tab for
>> "Trips" is highlighted here, meaning the graphs are done for *trips* (i.e.
>> the leftmost bar indicates a *trip* to Hoodsport). It would be very
>> valuable to include the number of dives in brackets after the name of the
>> trip, e.g. the trip to Hoodsport may be indicated as *Hoodsport, WA, USA
>> (6)*. The six in brackets would indicates that this trip comprised six
>> dives and that the leftmost bar for Hoodsport summarises six dives.
>>
>> Comment 2. In a statistics panel is would be proper to indicate the
>> measurement units (e.g. C or °F for temperature and m/ft for depth and
>> l/min or ft3/min for SAC.
>>
>> Comment 3. As Davide has argued, there is no reason to keep the depth
>> profile while showing statistics, because the depth profile has nothing to
>> do with the statistics being shown. On the other hand, since the dive list
>> shows which dives or trips have been selected and the map shows all dives
>> in an area, one could argue that these panels have some relevance to the
>> statistics being shown. Admitting that I know nothing of what the Qt/QML
>> implications may be, there is therefore no reason why the statistics panel
>> may not be extended to the right to cover the profile panel as well.
>>
>> Comment 4. For long trip names it is probably useful if only the first
>> 15-20 characters of a trip or dive site name is used, otherwise the
>> vertical space for creating graphs becomes very small. My own dive
>> localities have rather long names.
>>
>> Comment 5. It might enhance the readability of the graphs if, across the
>> panel, there are horizontal light grey lines that correspond to every 10
>> units on the vertical axis. This would allow easier interpretation of bars
>> located towards the right hand side of the panel.
>>
>> I hope you find this helpful. Thank you for your time and perseverance in
>> doing this. This is going to be a very nice feature.
>>
>> Kind regards,
>> willem
>>
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Bluetooth / BLE failing with Shearwater Petrel 2 on mobile and desktop

[Dirk Hohndel]

> On Aug 23, 2017, at 2:21 AM, Anton Lundin  wrote:
>>> From the libdivecomputer log:
>> INFO: Open: name=LE:00:13:43:0E:6B:D0
>> ERROR: Failed to open the serial port. [in ../../src/shearwater_common.c:46
>> (shearwater_common_open)]
>> 
>> Does anyone have any clue how to fix this?
> 
> I don't know if 5.7.1 is modern enough for BT LE stuff on bluez. There's
> a "// HACK ALERT! Qt 5.9 needs this for proper Bluez operation" and such
> which points one towards a modern Qt.

I think BLE will not work with any of the dive computers we have tried so far
unless you have at least Qt 5.9 - I have lost track (sorry), what the matrix is
on Linux, I think for the EON Steel you still need one patch on top of 5.9.1,
the G2 and the Shearwaters should work with 5.9.1.

> Test with a newer Qt. Newer is better? What could possibly go wrong?

A lot

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

Re: Bluetooth / BLE failing with Shearwater Petrel 2 on mobile and desktop

[Lubomir I. Ivanov]

On 23 August 2017 at 13:40, Salvador Cuñat  wrote:
> Hi
>
> 2017-08-23 11:55 GMT+02:00 Rick Walsh :
>>
>>
>>
>> On 23 Aug. 2017 19:21, "Anton Lundin"  wrote:
>>
>> On 23 August, 2017 - Rick Walsh wrote:
>>
>> > Hi,
>> >
>> ...
>>
>> > Downloading to my desktop (v4.6.4-737-g5de49401c89c, built with Qt5.7.1
>> > on
>> > Fedora 26) also fails now.
>>
>> > Does anyone have any clue how to fix this?
>>
>> I don't know if 5.7.1 is modern enough for BT LE stuff on bluez. There's
>> a "// HACK ALERT! Qt 5.9 needs this for proper Bluez operation" and such
>> which points one towards a modern Qt.
>>
>> Test with a newer Qt. Newer is better? What could possibly go wrong?
>>
>>
>
> On Debian unstable, moving to Qt 5.9 fails (since a week or two) because
> distro has moved to openssl 1.1 (as Linus pointed out some time ago). Didn't
> try on updated fedora for a while, but it's quite fast adding security
> updates.
>

ouch,

they would need to manually patch their Qt 5.9 build to support
openssl 1.1 or users would have to wait for the next Qt release (and
Debian needs to include that too) to be able to use Qt with openssl
1.1.

like some have pointed out - openssl 1.1 isn't really more secure than
the 1.0x series. on the other hand this move might break Qt apps for
thousands of people.
:facepalm:

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

Re: Bluetooth / BLE failing with Shearwater Petrel 2 on mobile and desktop

[Salvador Cuñat]

Hi

2017-08-23 11:55 GMT+02:00 Rick Walsh :

>
>
> On 23 Aug. 2017 19:21, "Anton Lundin"  wrote:
>
> On 23 August, 2017 - Rick Walsh wrote:
>
> > Hi,
> >
> ...
>
> > Downloading to my desktop (v4.6.4-737-g5de49401c89c, built with Qt5.7.1
> on
> > Fedora 26) also fails now.
>
> > Does anyone have any clue how to fix this?
>
> I don't know if 5.7.1 is modern enough for BT LE stuff on bluez. There's
> a "// HACK ALERT! Qt 5.9 needs this for proper Bluez operation" and such
> which points one towards a modern Qt.
>
> Test with a newer Qt. Newer is better? What could possibly go wrong?
>
>
>
On Debian unstable, moving to Qt 5.9 fails (since a week or two) because
distro has moved to openssl 1.1 (as Linus pointed out some time ago).
Didn't try on updated fedora for a while, but it's quite fast adding
security updates.

Regards

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

Re: Bluetooth / BLE failing with Shearwater Petrel 2 on mobile and desktop

[Miika Turkia]

On Wed, Aug 23, 2017 at 12:55 PM, Rick Walsh  wrote:
>
>
> On 23 Aug. 2017 19:21, "Anton Lundin"  wrote:
>
> On 23 August, 2017 - Rick Walsh wrote:
>
>> Hi,
>>
> ...
>
>> Downloading to my desktop (v4.6.4-737-g5de49401c89c, built with Qt5.7.1 on
>> Fedora 26) also fails now.
>
>> Does anyone have any clue how to fix this?
>
> I don't know if 5.7.1 is modern enough for BT LE stuff on bluez. There's
> a "// HACK ALERT! Qt 5.9 needs this for proper Bluez operation" and such
> which points one towards a modern Qt.
>
> Test with a newer Qt. Newer is better? What could possibly go wrong?
>
> I tried that today. Downloaded qt5.9.1, and used ccmake in subsurface/build
> to point to the right qt directories. But the build fails because it doesn't
> have webkit. Is there some trick to make it work?
>
> I downloaded dives succesfully on Windows 7 with the latest binary.

ccmake one more time, and switch to webengine

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

Re: Bluetooth / BLE failing with Shearwater Petrel 2 on mobile and desktop

[Rick Walsh]

On 23 Aug. 2017 19:21, "Anton Lundin"  wrote:

On 23 August, 2017 - Rick Walsh wrote:

> Hi,
>
...

> Downloading to my desktop (v4.6.4-737-g5de49401c89c, built with Qt5.7.1 on
> Fedora 26) also fails now.

> Does anyone have any clue how to fix this?

I don't know if 5.7.1 is modern enough for BT LE stuff on bluez. There's
a "// HACK ALERT! Qt 5.9 needs this for proper Bluez operation" and such
which points one towards a modern Qt.

Test with a newer Qt. Newer is better? What could possibly go wrong?

I tried that today. Downloaded qt5.9.1, and used ccmake in subsurface/build
to point to the right qt directories. But the build fails because it
doesn't have webkit. Is there some trick to make it work?

I downloaded dives succesfully on Windows 7 with the latest binary.

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

Re: Bluetooth / BLE failing with Shearwater Petrel 2 on mobile and desktop

[Anton Lundin]

On 23 August, 2017 - Rick Walsh wrote:

> Hi,
> 
...

> Downloading to my desktop (v4.6.4-737-g5de49401c89c, built with Qt5.7.1 on
> Fedora 26) also fails now.  From the command line:
> 
> build with Qt Version 5.7.1, runtime from Qt Version 5.7.1
> qt.bluetooth.bluez: Bluez 5 detected.
> qt.bluetooth.bluez: Creating QtBluezDiscoveryManager
> qt.bluetooth.bluez: Discovered:  "00:13:43:0E:6B:D0" "Petrel" Num UUIDs 3
> total device 0 cached RSSI 0 Class 0
> qt.bluetooth.bluez: Updating RSSI for "00:13:43:0E:6B:D0" QVariant(short,
> -59)
> qt.bluetooth.bluez: void QBluetoothDeviceDiscoveryAgentPrivate::stop()
> 
> INFO: FTDI disabled
> qt.bluetooth.bluez: No settings found for peer device.
> qt.bluetooth.bluez: HCI event triggered, type: e
> qt.bluetooth.bluez: HCI event triggered, type: e
> [12.217318] ERROR: Failed to open the serial port. [in
> ../../src/shearwater_common.c:46 (shearwater_common_open)]
> INFO: dc_deveice_open error value of -6
> 
> >From the libdivecomputer log:
> INFO: Open: name=LE:00:13:43:0E:6B:D0
> ERROR: Failed to open the serial port. [in ../../src/shearwater_common.c:46
> (shearwater_common_open)]
> 
> Does anyone have any clue how to fix this?

I don't know if 5.7.1 is modern enough for BT LE stuff on bluez. There's
a "// HACK ALERT! Qt 5.9 needs this for proper Bluez operation" and such
which points one towards a modern Qt.

Test with a newer Qt. Newer is better? What could possibly go wrong?


//Anton


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