Re: Scubapro Aladin Square

[Jef Driesen]

On 12-11-17 19:09, Linus Torvalds wrote:

On Sun, Nov 12, 2017 at 5:16 AM, vavincavent  wrote:


I try with joined file scubapro_g2.c to download from scubapro square.


Hmm. Can I see what the packets on the wire are, just in case we have
some odd libusb issue or something? We added an initial zero byte for
the report type to make hidapi happy, and *my* version of usblib
certainly didn't care, but...


The zero report id should be stripped in our usbhid backend when using libusb, 
so I doubt that's the problem.


Logtrak is using hidapi, so it might be worth trying to build libdivecomputer 
with hidapi instead of libusb (./configure --without-libusb). That will already 
rule out one difference. And maybe also try libdivecomputer/subsurface on 
windows too, because we know for sure downloading there works. If we can confirm 
it works on windows, then we can move one step at a time, and try to identify 
which step is the culprit (hidapi vs libusb, windows vs linux, etc).


I have prepared a hidapi based windows build for you. Just download these files:

http://libdivecomputer.org/builds/experimental/windows/g2.cmd
http://libdivecomputer.org/builds/experimental/windows/libdivecomputer-0.dll
http://libdivecomputer.org/builds/divinglog/libhidapi-0.dll
http://libdivecomputer.org/builds/divinglog/dctool.exe

Place everything in the same directory, and start the download by 
double-clicking the g2 batch file. When done, email us the g2.log file, and if 
present also the g2.bin file.


(I also patched the g2 backend with the VID/PID of the aladin square in this 
build.)


I think you said this is on debian. Use 'tshark -i usbmon1 -w
out.pcap" (replace 'usbmon1' with whatever bus the device is on) to
capture a packet trace.

You can use wireshark as a GUI tool of course. Usually I find it's
nicer to first capture on the command line, and then use wireshark to
look at things, but whatever works for you...


Yes, this is indeed something worth trying.

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

Re: OK, this is pretty cool

[Dirk Hohndel]

Enthusiastic ACK.
Please send pull request that shows how this would work.

On November 12, 2017 1:47:13 PM PST, "Lubomir I. Ivanov"  
wrote:
>On 12 November 2017 at 09:22, Dirk Hohndel  wrote:
>>
>> On Nov 11, 2017, at 10:53 PM, Stefan Fuchs  wrote:
>>
>> I would keep posting the subsurface.exe
>> When creating my own builds and testing I very often just replace the
>exe to
>> test s.th. because it's faster...
>>
>>
>> Either way is no problem. I need to figure out how to post better
>> explanations there, but that I'm pretty sure is easy to do.
>>
>
>i would like to bring something up again - 3rd time is charm.
>when a user reports a crash at some offset in the subsurface.exe,
>there is really no straightforward way of debugging the crash.
>i know that "real man" don't use debug symbols and dream in x86...but
>how about we facilitate this finally for the Windows build? :-)
>
>1) use "RelWithDebInfo":
>cmake  -DCMAKE_BUILD_TYPE=RelWithDebInfo
>(subsurface.exe is created with debug symbols but it's not linked to
>the debug version of Qt)
>
>2) objcopy --only-keep-debug subsurface.exe subsurface.exe.debug
>(copy the debug symbols to the .debug file)
>
>3) objcopy --strip-debug --strip-unneeded subsurface.exe
>(strip the debug symbols from the .exe)
>
>4) objcopy --add-gnu-debuglink=subsurface.exe.debug subsurface.exe
>(apply the debuglink thingy)
>
>5) upload subsurface.exe.debug next to the Windows build (~70MB for
>me) in the Github release
>
>results:
>- subsuface.exe is still a stripped down release build
>- gdb subsuface.exe
>reads debug symbols from the .debug file if it's in the same path as
>the .exe!
>- profit?
>
>maybe i can give it a try by just creating a new Github branch and
>messing with the Travis build as i don't have a MXE setup?
>
>ACK/NAK?
>
>lubomir
>--

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

Re: OK, this is pretty cool

[Lubomir I. Ivanov]

On 12 November 2017 at 09:22, Dirk Hohndel  wrote:
>
> On Nov 11, 2017, at 10:53 PM, Stefan Fuchs  wrote:
>
> I would keep posting the subsurface.exe
> When creating my own builds and testing I very often just replace the exe to
> test s.th. because it's faster...
>
>
> Either way is no problem. I need to figure out how to post better
> explanations there, but that I'm pretty sure is easy to do.
>

i would like to bring something up again - 3rd time is charm.
when a user reports a crash at some offset in the subsurface.exe,
there is really no straightforward way of debugging the crash.
i know that "real man" don't use debug symbols and dream in x86...but
how about we facilitate this finally for the Windows build? :-)

1) use "RelWithDebInfo":
cmake  -DCMAKE_BUILD_TYPE=RelWithDebInfo
(subsurface.exe is created with debug symbols but it's not linked to
the debug version of Qt)

2) objcopy --only-keep-debug subsurface.exe subsurface.exe.debug
(copy the debug symbols to the .debug file)

3) objcopy --strip-debug --strip-unneeded subsurface.exe
(strip the debug symbols from the .exe)

4) objcopy --add-gnu-debuglink=subsurface.exe.debug subsurface.exe
(apply the debuglink thingy)

5) upload subsurface.exe.debug next to the Windows build (~70MB for
me) in the Github release

results:
- subsuface.exe is still a stripped down release build
- gdb subsuface.exe
reads debug symbols from the .debug file if it's in the same path as the .exe!
- profit?

maybe i can give it a try by just creating a new Github branch and
messing with the Travis build as i don't have a MXE setup?

ACK/NAK?

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

Re: RFC: Subsurface 1-dive print layout

[Lubomir I. Ivanov]

On 12 November 2017 at 19:47, Willem Ferguson
 wrote:
> Attached is a print layout file and PDF rendering of a dive in the
> 1-dive-per-page version. The existing 1-dive layout has irked me quite a bit
> and for some time. Therefore I have messed a bit with the css/javascript to
> produce something that I think is closer to what I prefer. Note that the
> vertical boxes scale to the height required. For instance, if the box
> showing Location name requires more depth because of multiple lines, the
> other boxes in the RH column adapt accordingly. The box for the dive notes
> also scales to adapt to the amount of text.
>
> If someone more proficient than myself in css/javascript is prepared to look
> through the code, I would really appreciate it. Some of the stuff is really
> hacky.
>
> But if I could have a few comments on whether this really represents an
> improvement and not merely a hack to suit Ferguson's taste, I would
> appreciate it.
>

i'm far from a CSS expert myself, even if technically i maintain the
templates in subsurface nowadays.
i would say that the if this works for you - that's great!

i can comment on this bit:
> "// number of characters in the string"
this isn't a very portable way because if you change the font the
calculations might end up being wrong without estimating actual font
glyph metrics.

it's probably best if we leave the stock template without the
auto-expansion, as it getting it right might be difficult for us - the
non-experts.
maybe, if we start getting *a lot* of change-requests about this we
can ponder on the best ways of doing it.

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

Re: Scubapro Aladin Square

[Linus Torvalds]

On Sun, Nov 12, 2017 at 5:16 AM, vavincavent  wrote:
>
> I try with joined file scubapro_g2.c to download from scubapro square.

Hmm. Can I see what the packets on the wire are, just in case we have
some odd libusb issue or something? We added an initial zero byte for
the report type to make hidapi happy, and *my* version of usblib
certainly didn't care, but...

I think you said this is on debian. Use 'tshark -i usbmon1 -w
out.pcap" (replace 'usbmon1' with whatever bus the device is on) to
capture a packet trace.

You can use wireshark as a GUI tool of course. Usually I find it's
nicer to first capture on the command line, and then use wireshark to
look at things, but whatever works for you...

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

Re: latest AppImage - getting closer

[Jan Mulder]

On 12-11-17 17:01, Dirk Hohndel wrote:



On Nov 12, 2017, at 4:56 AM, Jan Mulder  wrote:

On 12-11-17 13:35, Lubomir I. Ivanov wrote:

On 12 November 2017 at 07:26, Willem Ferguson
 wrote:


Below is the output. Its greek to me, I just followed the recipe
mechanically.

i can't find any outstanding errors in the log; all libraries are
present, no bad calls to CUPS.
so in a way, i have no idea why the hard copy printing isn't working
via the AppImage.
one good question here is, did it ever work - e.g. with older
AppImages e.g. Subsurface 4.6?
lubomir


Just tested print on hardware (from the AppImage). Works just fine on my box.


That is interesting, given Willem's results and those of others.

Which distro are you running?

Arch Linux (with very recent pacman Syu).

--jan

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

Re: latest AppImage - getting closer

[Dirk Hohndel]

> On Nov 12, 2017, at 6:40 AM, Willem Ferguson 
>  wrote:
> 
> On 12/11/2017 14:35, Lubomir I. Ivanov wrote:
>> On 12 November 2017 at 07:26, Willem Ferguson
>>  wrote:
>>> Below is the output. Its greek to me, I just followed the recipe
>>> mechanically.
>> i can't find any outstanding errors in the log; all libraries are
>> present, no bad calls to CUPS.
>> so in a way, i have no idea why the hard copy printing isn't working
>> via the AppImage.
>> 
>> one good question here is, did it ever work - e.g. with older
>> AppImages e.g. Subsurface 4.6?
>> 
>> lubomir
>> --
>> 
> I have AppImage 4.6.3-287 here. On that program I cannot see any hardware 
> printers. There is only an opportunity for selecting PDF. On the new AppImage 
> I can see all hardware printers (see attached images) but the printing does 
> not produce output. I checked on the Subsurface download site and got 
> AppImage 4.5.1-1600. There it is the same as on 4.6.3 : can only select PDF 
> and cannot see print hardware.

So at least we know it's not a new regression - which makes me a lot less 
worried :-)

> The latest version that I can download from the Ubuntu repository is 
> 4.7.2-74.  It also prints perfectly.

So on Ubuntu you can only print to PDF. I think that's a flaw that we can live 
with.

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

Re: latest AppImage - getting closer

[Dirk Hohndel]

> On Nov 12, 2017, at 4:56 AM, Jan Mulder  wrote:
> 
> On 12-11-17 13:35, Lubomir I. Ivanov wrote:
>> On 12 November 2017 at 07:26, Willem Ferguson
>>  wrote:
>>> 
>>> Below is the output. Its greek to me, I just followed the recipe
>>> mechanically.
>> i can't find any outstanding errors in the log; all libraries are
>> present, no bad calls to CUPS.
>> so in a way, i have no idea why the hard copy printing isn't working
>> via the AppImage.
>> one good question here is, did it ever work - e.g. with older
>> AppImages e.g. Subsurface 4.6?
>> lubomir
> 
> Just tested print on hardware (from the AppImage). Works just fine on my box.

That is interesting, given Willem's results and those of others.

Which distro are you running?

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

Re: OK, this is pretty cool

[Dirk Hohndel]

> On Nov 12, 2017, at 12:52 AM, Anton Lundin  wrote:
> 
> Yea, its a old and obsolete variant. Just trying to give you some
> examples on how it was done once back in time.

Much appreciated

> Btw. What still requires QtWebKit? Printing?

As was discussed a few times:
- printing
- Facebook (which doesn't log in when using an AppImage)

>>> I also have a version which builds a android apk:
>>> https://github.com/glance-/subsurface/blob/master_travis_android_docker/.travis.yml
>> 
>> Cool, definitely something we should add. Feel free to bring this up to the 
>> latest master and send a pull request!
> 
> The matrix-bits are already there so it should be a quite quick thing to
> do. I'll try to get it done.

Excellent

>>> I like the trick of running a docker container with the dependencies we
>>> need for running the build in. That way you get full control of the
>>> environment and you don't need to rely on the quite messy travis images.
>> 
>> I don't know how to do that in general and I don't think we can do this for 
>> Mac in particular.
> 
> Thats the trick used in the android builds above.

OK, I'll need to study this more. AFTER I have a working Mac build.

>>> The only other thing I can recommend is to automate building our MXE
>>> environment and our Qt-builds to.
>> 
>> I don't know what that would gain me. On a machine that I can ssh into (or 
>> that's local to me) I can usually get these builds going.
>> Except making it 100 times harder and a 1000 times more painful, what would 
>> be the benefit of doing this?
> 
> It will give us the same benefit as having travis doing our builds. Yea,
> you did them by hand for quite a while, now travis does them for us.
> 
> Its easier for others to replicate, reproduce and debug if the scripts
> to build those tar-balls where available, and even better if travis
> produced them by it self.
> 
> A good sysadmin replaces him self with as much automation as possible =)

Point taken. So I'll stop working on Subsurface for a bit and work on Travis 
instead.

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

Re: latest AppImage - getting closer

[Jan Mulder]

On 12-11-17 13:35, Lubomir I. Ivanov wrote:

On 12 November 2017 at 07:26, Willem Ferguson
 wrote:


Below is the output. Its greek to me, I just followed the recipe
mechanically.


i can't find any outstanding errors in the log; all libraries are
present, no bad calls to CUPS.
so in a way, i have no idea why the hard copy printing isn't working
via the AppImage.

one good question here is, did it ever work - e.g. with older
AppImages e.g. Subsurface 4.6?

lubomir


Just tested print on hardware (from the AppImage). Works just fine on my 
box.


--jan

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

Re: latest AppImage - getting closer

[Lubomir I. Ivanov]

On 12 November 2017 at 07:26, Willem Ferguson
 wrote:
>
> Below is the output. Its greek to me, I just followed the recipe
> mechanically.

i can't find any outstanding errors in the log; all libraries are
present, no bad calls to CUPS.
so in a way, i have no idea why the hard copy printing isn't working
via the AppImage.

one good question here is, did it ever work - e.g. with older
AppImages e.g. Subsurface 4.6?

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

Re: OK, this is pretty cool

[Anton Lundin]

On 12 November, 2017 - Dirk Hohndel wrote:

> 
> > On Nov 11, 2017, at 11:49 PM, Anton Lundin  wrote:
> > 
> > I had a old .travis.yml building Subsurface on os x:
> > https://github.com/glance-/subsurface/blob/obsolete/master_travis_osx/.travis.yml
> 
> I took a quick look. So easy. If only it was that easy for me. But then it's 
> always possible
> that I'm just doing something really stupid.
> 
> I absolutely cannot get googlemaps to build. I have simply given up to deal 
> with that later because otherwise I might punch something.
> The above is based on Marble and it uses an old Qt which included WebKit.
> 
> Today we need Qt 5.9.1+ with QtWebKit so we need to build this ourselves.
> Googlemaps happily compiles against EXACTLY that Qt installation here on my 
> Mac. And fails in a million idiotic ways with qmake errors when used on 
> Travis.

Yea, its a old and obsolete variant. Just trying to give you some
examples on how it was done once back in time.

Btw. What still requires QtWebKit? Printing?

> 
> > I also have a version which builds a android apk:
> > https://github.com/glance-/subsurface/blob/master_travis_android_docker/.travis.yml
> 
> Cool, definitely something we should add. Feel free to bring this up to the 
> latest master and send a pull request!

The matrix-bits are already there so it should be a quite quick thing to
do. I'll try to get it done.

> > I like the trick of running a docker container with the dependencies we
> > need for running the build in. That way you get full control of the
> > environment and you don't need to rely on the quite messy travis images.
> 
> I don't know how to do that in general and I don't think we can do this for 
> Mac in particular.

Thats the trick used in the android builds above.

> 
> > The only other thing I can recommend is to automate building our MXE
> > environment and our Qt-builds to.
> 
> I don't know what that would gain me. On a machine that I can ssh into (or 
> that's local to me) I can usually get these builds going.
> Except making it 100 times harder and a 1000 times more painful, what would 
> be the benefit of doing this?

It will give us the same benefit as having travis doing our builds. Yea,
you did them by hand for quite a while, now travis does them for us.

Its easier for others to replicate, reproduce and debug if the scripts
to build those tar-balls where available, and even better if travis
produced them by it self.

A good sysadmin replaces him self with as much automation as possible =)


Or now when Star Trek is running again:

Dammit Jim - I'm A Sysadmin not a Babysitter


//Anton - Who's a babysitter once again


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

Re: OK, this is pretty cool

[Dirk Hohndel]

> On Nov 11, 2017, at 11:49 PM, Anton Lundin  wrote:
> 
> I had a old .travis.yml building Subsurface on os x:
> https://github.com/glance-/subsurface/blob/obsolete/master_travis_osx/.travis.yml

I took a quick look. So easy. If only it was that easy for me. But then it's 
always possible
that I'm just doing something really stupid.

I absolutely cannot get googlemaps to build. I have simply given up to deal 
with that later because otherwise I might punch something.
The above is based on Marble and it uses an old Qt which included WebKit.

Today we need Qt 5.9.1+ with QtWebKit so we need to build this ourselves.
Googlemaps happily compiles against EXACTLY that Qt installation here on my 
Mac. And fails in a million idiotic ways with qmake errors when used on Travis.

> I also have a version which builds a android apk:
> https://github.com/glance-/subsurface/blob/master_travis_android_docker/.travis.yml

Cool, definitely something we should add. Feel free to bring this up to the 
latest master and send a pull request!

> I like the trick of running a docker container with the dependencies we
> need for running the build in. That way you get full control of the
> environment and you don't need to rely on the quite messy travis images.

I don't know how to do that in general and I don't think we can do this for Mac 
in particular.

> The only other thing I can recommend is to automate building our MXE
> environment and our Qt-builds to.

I don't know what that would gain me. On a machine that I can ssh into (or 
that's local to me) I can usually get these builds going.
Except making it 100 times harder and a 1000 times more painful, what would be 
the benefit of doing this?

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