Re: preparing for 5.0.2

[Gaetan Bisson via subsurface]

Hi Dirk,
Hi everyone,

The sad news concerning Arch is that I resigned my role as a developer a
while ago due to lack of time and they apparently haven't found any
other dev/TU interested to keep maintaining a subsurface package in the
official repos.

There are still user-contributed packages in the AUR:

- subsurface-git and subsurface-libdc-git, both of which I maintain.
  Their PKGBUILD only needs to be updated when the build process
  changes. Otherwise, a simple `makepkg` will pull and build the latest
  git snapshot.

- subsurface and subsurface-libdc (stable versions) have been dropped
  there from the official repos and nobody has touched them since.

So I would say Arch users are better off using the AppImage unless they
wish to compile and run subsurface-git.

Cheers.

-- 
Gaetan


On 02 Jul 2021 at 13:11 -0700, Dirk Hohndel wrote:
> #insert usual lament about overall lack of testing these days
> 
> Apparently my CI hadn't build AppImages in more than two months. I hadn't 
> noticed.
> Looking at download stats, and trying to filter out bots, the number of times 
> the daily test builds are downloaded are... demoralizing.
> For 99+% of them the only downloads are clearly bots. And many of the real 
> downloads are the result of one of us pointing users to those builds to see 
> if they fix a bug.
> 
> Oh well. I fixed the AppImage build problem. I fixed yet another config issue 
> that prevented the Launchpad Hirsute build from working. I fixed a different 
> issue with the OBS builds for RPM based distros.
> I believe everything is pushed (sources, tags, tar balls, binaries for all 
> platforms that I build for plus distro builds that I can push for)
> 
> A draft announcement is in the GitHub.io repo if people feel like translating 
> those.
> 
> Richard - how do you trigger your Debian builds? Is that automatic or do you 
> need to do this manually? Have they been tested enough that we would want to 
> advertise them to interested users?
> I believe Gaetan's builds are automated for ArchLinux? Should we add 
> instructions for those to the website?
> Is there anyone else created unofficial builds that we might want to start 
> mentioning?
> 
> /D
> 
> > On Jun 29, 2021, at 4:12 PM, Dirk Hohndel via subsurface 
> >  wrote:
> > 
> > Hi Everyone
> > 
> > There are a number of bug fixes that really deserve a release - and as a 
> > side effect that will give us an out-of-the box working version on Ubuntu 
> > 21.04 / Hirsute.
> > I am pulling the latest translations and am getting the README / 
> > ReleaseNotes ready.
> > One area that could REALLY use some testing is printing. We are in the 
> > middle of a bunch of changes of that code and we want to make sure we 
> > understand if anything broke there.
> > So... if you have a moment (especially if you are on Mac and Windows), 
> > would you please try the current daily builds, and try the printing 
> > features?
> > 
> > Thanks
> > 
> > /D
> > ___
> > 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: preparing for 5.0.2

[Gaetan Bisson via subsurface]

Hi Dirk,
Hi everyone,

The sad news concerning Arch is that I resigned my role as a developer a
while ago due to lack of time and they apparently haven't found any
other dev/TU interested to keep maintaining a subsurface package in the
official repos.

There are still user-contributed packages in the AUR:

- subsurface-git and subsurface-libdc-git, both of which I maintain.
  Their PKGBUILD only needs to be updated when the build process
  changes. Otherwise, a simple `makepkg` will pull and build the latest
  git snapshot.

- subsurface and subsurface-libdc (stable versions) have been dropped
  there from the official repos and nobody has touched them since.

So I would say Arch users are better off using the AppImage unless they
wish to compile and run subsurface-git.

Cheers.

-- 
Gaetan


On 02 Jul 2021 at 13:11 -0700, Dirk Hohndel wrote:
> #insert usual lament about overall lack of testing these days
> 
> Apparently my CI hadn't build AppImages in more than two months. I hadn't 
> noticed.
> Looking at download stats, and trying to filter out bots, the number of times 
> the daily test builds are downloaded are... demoralizing.
> For 99+% of them the only downloads are clearly bots. And many of the real 
> downloads are the result of one of us pointing users to those builds to see 
> if they fix a bug.
> 
> Oh well. I fixed the AppImage build problem. I fixed yet another config issue 
> that prevented the Launchpad Hirsute build from working. I fixed a different 
> issue with the OBS builds for RPM based distros.
> I believe everything is pushed (sources, tags, tar balls, binaries for all 
> platforms that I build for plus distro builds that I can push for)
> 
> A draft announcement is in the GitHub.io repo if people feel like translating 
> those.
> 
> Richard - how do you trigger your Debian builds? Is that automatic or do you 
> need to do this manually? Have they been tested enough that we would want to 
> advertise them to interested users?
> I believe Gaetan's builds are automated for ArchLinux? Should we add 
> instructions for those to the website?
> Is there anyone else created unofficial builds that we might want to start 
> mentioning?
> 
> /D
> 
> > On Jun 29, 2021, at 4:12 PM, Dirk Hohndel via subsurface 
> >  wrote:
> > 
> > Hi Everyone
> > 
> > There are a number of bug fixes that really deserve a release - and as a 
> > side effect that will give us an out-of-the box working version on Ubuntu 
> > 21.04 / Hirsute.
> > I am pulling the latest translations and am getting the README / 
> > ReleaseNotes ready.
> > One area that could REALLY use some testing is printing. We are in the 
> > middle of a bunch of changes of that code and we want to make sure we 
> > understand if anything broke there.
> > So... if you have a moment (especially if you are on Mac and Windows), 
> > would you please try the current daily builds, and try the printing 
> > features?
> > 
> > Thanks
> > 
> > /D
> > ___
> > 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: renaming the default branch to 'main'

[Gaetan Bisson via subsurface]

[2020-06-15 13:01:04 -0700] Dirk Hohndel via subsurface:
> I strongly believe that words matter. And that sometimes it's the small 
> things where we can show respect.

Shall we rename divemaster too? As an explicit GUI label it gets much
more user exposure than the default branch name. I would suggest dive
leader but it is probably just as offensive due to its resemblance to
nazi titles.

Cheers.

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

Re: Git-related segfault in master

[Gaetan Bisson]

[2020-02-17 09:54:28 -0800] Linus Torvalds:
> Gaetan, I'd suggest blowing away your tree and re-building from
> scratch, in case it's some stale object file and a libgit update
> interacting badly?

Thanks, it was actually the upgrade of http-parser (which libgit2
depends on) from 2.9.2 to 2.9.3 which caused the problem.

Cheers.

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

Git-related segfault in master

[Gaetan Bisson]

Hi,

Building today's master (4c5054ec4) on an up-to-date Arch Linux system
(with libgit2-0.28.4) I get a binary which runs fine until it tries to
connect to the cloud service. It then segfaults with the following
backtrace:

#0  0x75b05e74 in  () at /usr/lib/libgit2.so.28
#1  0x7fffef89f182 in http_parser_execute () at 
/usr/lib/libhttp_parser.so.2.9
#2  0x75b07391 in  () at /usr/lib/libgit2.so.28
#3  0x75b09771 in  () at /usr/lib/libgit2.so.28
#4  0x75b0bb59 in  () at /usr/lib/libgit2.so.28
#5  0x75b09f92 in  () at /usr/lib/libgit2.so.28
#6  0x75ae6347 in git_remote_fetch () at /usr/lib/libgit2.so.28
#7  0x558745fb in sync_with_remote (rt=RT_HTTPS, branch=0x5b31cc60 
"gae...@fenua.org", remote=0x5b31c7c0 
"https://cloud.subsurface-divelog.org//git/gae...@fenua.org;, 
repo=0x5c97b840) at 
/opt/arch/aur/subsurface-git/src/subsurface/core/git-access.c:653
#8  sync_with_remote (repo=0x5c97b840, remote=0x5b31c7c0 
"https://cloud.subsurface-divelog.org//git/gae...@fenua.org;, 
branch=0x5b31cc60 "gae...@fenua.org", rt=RT_HTTPS) at 
/opt/arch/aur/subsurface-git/src/subsurface/core/git-access.c:598
#9  0x55875aab in update_local_repo (rt=RT_HTTPS, branch=0x5b31cc60 
"gae...@fenua.org", remote=0x5b31c7c0 
"https://cloud.subsurface-divelog.org//git/gae...@fenua.org;, 
localdir=0x5b31d100 
"/home/bisson/.subsurface/cloudstorage/831e8034da33af46")
at /opt/arch/aur/subsurface-git/src/subsurface/core/git-access.c:692
#10 get_remote_repo (branch=0x5b31cc60 "gae...@fenua.org", 
remote=0x5b31c7c0 
"https://cloud.subsurface-divelog.org//git/gae...@fenua.org;, 
localdir=0x5b31d100 
"/home/bisson/.subsurface/cloudstorage/831e8034da33af46")
at /opt/arch/aur/subsurface-git/src/subsurface/core/git-access.c:845
#11 is_remote_git_repository (branch=, remote=) 
at /opt/arch/aur/subsurface-git/src/subsurface/core/git-access.c:933
#12 is_git_repository (filename=, filename@entry=0x5ac816f8 
"https://cloud.subsurface-divelog.org//git/gae...@fenua.org[gae...@fenua.org];, 
branchp=branchp@entry=0x7fffdfd8, remote=remote@entry=0x0, 
dry_run=dry_run@entry=false)
at /opt/arch/aur/subsurface-git/src/subsurface/core/git-access.c:1004
#13 0x55872c67 in parse_file (filename=0x5ac816f8 
"https://cloud.subsurface-divelog.org//git/gae...@fenua.org[gae...@fenua.org];, 
table=0x55af5ad0 , trips=0x55af6080 , 
sites=0x55af5a80 )
at /opt/arch/aur/subsurface-git/src/subsurface/core/file.c:305
#14 0x5569d938 in MainWindow::loadFiles(QStringList) 
(this=0x55e00890, fileNames=...) at /usr/include/qt/QtCore/qarraydata.h:61
#15 0x55689b07 in main(int, char**) (argc=, 
argv=) at /usr/include/qt/QtCore/qstringlist.h:111

Please tell me it's not just me. :)

Cheers.

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

Re: Segfault in OstcFirmwareCheck::checkLatest

[Gaetan Bisson]

Hi Anton,

[2020-01-10 16:51:26 -1000] Gaetan Bisson:
> I'll double check later this weekend.

I can't seem to be able to reproduce the segfault anymore. It could very
well be that I misdiagnosed the problem and was in fact facing the issue
Jan described. Sorry for the confusion.

Cheers.

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

Re: Segfault in OstcFirmwareCheck::checkLatest

[Gaetan Bisson]

Hi Anton,

[2020-01-10 23:27:04 +0100] Anton Lundin:
> On 09 January, 2020 - Gaetan Bisson wrote:
> 
> > Hi Anton,
> > 
> > [2020-01-09 20:47:59 +0100] Anton Lundin:
> > > So, can you re-run this and provide a libdivecomptuer logfile? I'd like
> > > to see what the device actually says.
> > 
> > Please find the log file attached. Let me know if there's anything else
> > you'd like to know/have.
> > 
> 
> > Subsurface: v4.9.3-733-g042799eb2a4e, built with libdivecomputer 
> > v0.7.0-devel-Subsurface-NG (4eb34b1466e7dff3ee2c0dfbeeef3642c2166d8c)
> > INFO: Open: name=/dev/ttyUSB0
> > 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=1, data=BB
> > INFO: Read: size=1, data=BB
> > INFO: Read: size=1, data=4D
> > INFO: Write: size=1, data=60
> > INFO: Read: size=1, data=60
> > INFO: Read: size=5, data=000A00
> > INFO: Read: size=1, data=4D
> > INFO: Write: size=1, data=69
> > INFO: Read: size=1, data=69
> > INFO: Read: size=64, 
> > data=090A03074857204F5354432020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020
> > INFO: Read: size=1, data=4D
> > Event: model=10 (0x000a), firmware=775 (0x0307), serial=2569 
> > (0x0a09)
> 
> The mind boggles. This device clearly identifies itself as a OSTC 3.
> 
> How can strcmp(data->product, "OSTC 4") == 0 be true then?

Sorry but the device isn't with me right now.

I'll double check later this weekend.

Cheers.

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

Re: Segfault in OstcFirmwareCheck::checkLatest

[Gaetan Bisson]

[2020-01-08 15:55:34 -1000] Gaetan Bisson:
> I just rebuilt subsurface from current git master and am getting a
> segfault when downloading dives from my OSTC3. The problem appears to be
> in OstcFirmwareCheck::checkLatest. I'm attaching the full backtrace of
> the crash. I'll investigate more later unless someone beats me to it.

So the problem seems to be that I've got an OSTC3 yet the following
assertion holds:

strcmp(data->product, "OSTC 4") == 0)

Since apparently it's libdivecomputer that populates the device_data
struct, I'd like to report this to them but I don't see any recent
change that might have broken this, and this issue certainly did not
exist in mid-december. I'll dig more but for now I'm a bit confused.

Cheers.

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

Segfault in OstcFirmwareCheck::checkLatest

[Gaetan Bisson]

Dear list,

I just rebuilt subsurface from current git master and am getting a
segfault when downloading dives from my OSTC3. The problem appears to be
in OstcFirmwareCheck::checkLatest. I'm attaching the full backtrace of
the crash. I'll investigate more later unless someone beats me to it.

Happy new year!

-- 
Gaetan
ASSERT failure in QList::operator[]: "index out of range", file 
/usr/include/qt/QtCore/qlist.h, line 579

Thread 1 "subsurface" received signal SIGABRT, Aborted.
0x7fffefd1bf25 in raise () from /usr/lib/libc.so.6
(gdb) bt full
#0  0x7fffefd1bf25 in raise () at /usr/lib/libc.so.6
#1  0x7fffefd05897 in abort () at /usr/lib/libc.so.6
#2  0x55664175 in messageHandler(QtMsgType, QMessageLogContext const&, 
QString const&) (type=, msg=...) at 
/opt/arch/aur/subsurface-git/src/subsurface/subsurface-desktop-main.cpp:241
localMsg = {d = 0x5c948930}
#3  0x702b4ad8 in  () at /usr/lib/libQt5Core.so.5
#4  0x702b4bea in  () at /usr/lib/libQt5Core.so.5
#5  0x70281952 in QMessageLogger::fatal(char const*, ...) const () at 
/usr/lib/libQt5Core.so.5
#6  0x70280d52 in  () at /usr/lib/libQt5Core.so.5
#7  0x5566bd99 in QList::operator[](int) (i=, 
this=) at /usr/include/qt/QtCore/qstringlist.h:111
X = 
Y = 
Z = 
beta = 
firmwareOnDevice = 775
firmwareOnDeviceString = {static null = {}, d = 
0x57300900}
fwParts =
  {> = {> = {}, {p = {static shared_null = {ref = {atomic = {_q_value = 
{> = {static _S_alignment = 4, _M_i = -1}, }}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x57302ac0}, 
d = 0x57302ac0}}, }
latestFirmwareAvailableNumber = 
#8  0x5566bd99 in OstcFirmwareCheck::checkLatest(QWidget*, 
dc_user_device_t*) (this=this@entry=0x7fffb4008030, 
_parent=_parent@entry=0x7fffcd90, data=) at 
/opt/arch/aur/subsurface-git/src/subsurface/desktop-widgets/configuredivecomputerdialog.cpp:290
X = 
Y = 
Z = 
beta = 
firmwareOnDevice = 775
firmwareOnDeviceString = {static null = {}, d = 
0x57300900}
fwParts =
  {> = {> = {}, {p = {static shared_null = {ref = {atomic = {_q_value = 
{> = {static _S_alignment = 4, _M_i = -1}, }}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x57302ac0}, 
d = 0x57302ac0}}, }
latestFirmwareAvailableNumber = 
#9  0x55759726 in DownloadFromDCWidget::on_ok_clicked() 
(this=0x7fffcd90) at 
/opt/arch/aur/subsurface-git/src/subsurface/desktop-widgets/downloadfromdivecomputer.cpp:550
tables = {first = {nr = 0, allocated = 48, dives = 0x7fffbc001c00}, 
second = {nr = 0, allocated = 0, dive_sites = 0x0}}
#10 0x556e55b4 in DownloadFromDCWidget::qt_static_metacall(QObject*, 
QMetaObject::Call, int, void**) (_o=, _c=, 
_id=, _a=0x7fffbfa0)
at 
/opt/arch/aur/subsurface-git/src/subsurface/build/desktop-widgets/subsurface_interface_autogen/EWIEGA46WW/moc_downloadfromdivecomputer.cpp:152
_t = 
#11 0x556e7813 in DownloadFromDCWidget::qt_metacall(QMetaObject::Call, 
int, void**) (this=0x7fffcd90, _c=QMetaObject::InvokeMetaMethod, _id=1, 
_a=0x7fffbfa0)
at 
/opt/arch/aur/subsurface-git/src/subsurface/build/desktop-widgets/subsurface_interface_autogen/EWIEGA46WW/moc_downloadfromdivecomputer.cpp:208
#12 0x704cd082 in  () at /usr/lib/libQt5Core.so.5
#13 0x71d74dc3 in QAbstractButton::clicked(bool) () at 
/usr/lib/libQt5Widgets.so.5
#14 0x71d74fec in  () at /usr/lib/libQt5Widgets.so.5
#15 0x71d763f2 in  () at /usr/lib/libQt5Widgets.so.5
#16 0x71d765b6 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () 
at /usr/lib/libQt5Widgets.so.5
#17 0x71cbe7e6 in QWidget::event(QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#18 0x71c7a472 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() at /usr/lib/libQt5Widgets.so.5
#19 0x71c83ed8 in QApplication::notify(QObject*, QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#20 0x70497832 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at /usr/lib/libQt5Core.so.5
#21 0x71c82ff6 in QApplicationPrivate::sendMouseEvent(QWidget*, 
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool, bool) () 
at /usr/lib/libQt5Widgets.so.5
#22 0x71cd9f91 in  () at /usr/lib/libQt5Widgets.so.5
#23 0x71cdcf14 in  () at /usr/lib/libQt5Widgets.so.5
#24 0x71c7a472 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() at /usr/lib/libQt5Widgets.so.5
#25 0x71c83c89 in QApplication::notify(QObject*, QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#26 0x70497832 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at /usr/lib/libQt5Core.so.5
#27 0x70fac2c4 in 
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
 () at /usr/lib/libQt5Gui.so.5
#28 0x70fad9d6 in 

Segfault when removing a cylinder

[Gaetan Bisson]

Dear all,

With current git master I'm consistently getting a segfault when trying
to remove a row from the Cylinders table in the Equipment tab, simply by
clicking on the trash bin icon.

The segfault occurs inside CylindersModel::remove(). I do not understand
much of that code but what I could piece together is the following:

- index.row() is +1 until the call to endRemoveRows()
- index.row() becomes -1 after the call to endRemoveRows()
- std::iota() then segfaults because its second argument is smaller than its 
first

Let me know if there's anything I could help test to fix this.

Cheers.

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

Re: web server update

[Gaetan Bisson]

Hi Dirk,

The download links are broken on:

https://subsurface-divelog.org/download/

They point to the domain "placeholder.wpsho" which it took me a few
minutes to realize is probably WordPress related...

Cheers.

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

Re: Mares genius

[Gaetan Bisson]

[2019-02-04 22:13:15 +0100] Jef Driesen:
> On 4/02/19 21:59, Gaetan Bisson wrote:
> > [2019-02-04 11:59:34 +0100] didier duriez:
> > > j'utilise comme ordinateur, un Mares Genius, je ne le trouve pas dans 
> > > votre liste d'ordinateur,
> > 
> > Notre logiciel communique avec les ordinateurs de plongée par le biais
> > de cette bibliothèque :
> > 
> > https://libdivecomputer.org/
> > 
> > Même s'il n'est pas explicitement mentionné dans la documentation, le
> > Genius est peut-être supporté car c'est le successeur direct du Icon HD
> > qui lui est supporté. Si vos tests confirment que c'est le cas, la liste
> > pourra être mise à jour.
> 
> I already had a quick look at the Genius, and at first sight it seems the
> data format has changed. So unfortunately this one is going to be a bit more
> work than just updating the list.
> 
> The download protocol is still the same, so downloading a memory dump works.
> Sending me the libdivecomputer logfile and a memory dump will certainly help
> me to get the Genius supported.

Thanks Jef; I'll translate your message to Didier and see if he can get
you this data.

Cheers.

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

Re: Mares genius

[Gaetan Bisson]

Bonjour,

[2019-02-04 11:59:34 +0100] didier duriez:
> j'utilise comme ordinateur, un Mares Genius, je ne le trouve pas dans votre 
> liste d'ordinateur,

Notre logiciel communique avec les ordinateurs de plongée par le biais
de cette bibliothèque :

https://libdivecomputer.org/

Même s'il n'est pas explicitement mentionné dans la documentation, le
Genius est peut-être supporté car c'est le successeur direct du Icon HD
qui lui est supporté. Si vos tests confirment que c'est le cas, la liste
pourra être mise à jour.

Bien cordialement.

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

Re: Mares genius

[Gaetan Bisson]

Bonjour,

[2019-02-04 11:59:34 +0100] didier duriez:
> j'utilise comme ordinateur, un Mares Genius, je ne le trouve pas dans votre 
> liste d'ordinateur,

Notre logiciel communique avec les ordinateurs de plongée par le biais
de cette bibliothèque :

https://libdivecomputer.org/

Même s'il n'est pas explicitement mentionné dans la documentation, le
Genius est peut-être supporté car c'est le successeur direct du Icon HD
qui lui est supporté. Si vos tests confirment que c'est le cas, la liste
pourra être mise à jour.

Bien cordialement.

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

Re: Website migration

[Gaetan Bisson]

[2018-12-31 09:30:54 -0800] Dirk Hohndel:
> OK, second try.
> Please commence the stress testing. And let me know what fails.

Same thing as yesterday for me. :(

$ curl --verbose https://subsurface-divelog.org/
*   Trying 54.68.64.159...
* TCP_NODELAY set
* Connected to subsurface-divelog.org (54.68.64.159) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: OU=Domain Control Validated; CN=*.subsurface-divelog.org
*  start date: Oct  6 10:39:31 2014 GMT
*  expire date: Oct  6 10:39:31 2019 GMT
*  subjectAltName: host "subsurface-divelog.org" matched cert's 
"subsurface-divelog.org"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=AlphaSSL CA - SHA256 - G2
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: subsurface-divelog.org
> User-Agent: curl/7.63.0
> Accept: */*
>

And then timeout.

Cheers.

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

Re: Cloud storage does not load at startup since b9b1f03

[Gaetan Bisson]

[2018-07-27 21:36:45 +0200] Jan Iversen:
> Master was just updated with my fix, I hope that solves your problem.

Thanks Jan, this indeed fixes my problem. Cheers.

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

Re: Cloud storage does not load at startup since b9b1f03

[Gaetan Bisson]

Hi Jan,

Just another remark (and I hope you can reproduce this): my issue is not
limited to auto loading cloud storage on startup; even if I manually
click on "File -> Open cloud storage" then nothing happens and the dive
list remains empty.

Loading XML files work and reverting to any commit before b9b1f03 fixes
the cloud storage issue.

Cheers.

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

Re: Cloud storage does not load at startup since b9b1f03

[Gaetan Bisson]

[2018-07-24 20:34:48 +0200] Jan Iversen:
> I was finally able to confirm the problem.
> 
> I used a local xml profile and that prohibits cloud automatic loading, with a 
> cloud based default xml, I can reproduce the problem, which is somewhere in 
> qPrefCloudStorage.
> 
> Sorry for the multiple mails, but this one was not intuitive to confirm. I 
> still have to understand why using a local profile stops automatic loading.
> 
> I am on debugging and hope to have a PR ready very soon.

Thanks so much for looking into this, Jan.

And sorry for my lack of response to your other messages: I sent my
email yesterday evening quite tired after a day of diving and went
straight to bed afterwards... :)

Cheers.

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

Cloud storage does not load at startup since b9b1f03

[Gaetan Bisson]

Hi Jan,

I run a build of Subsurface's latest git master but since b9b1f03 I find
that cloud storage does not load upon startup as it used to.

Is there any settings or such things I need to migrate to conform with
the new qPrefCloudStorage?

Cheers.

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

Re: Segfault with Qt-5.11.0

[Gaetan Bisson]

[2018-05-24 23:04:28 +0200] Berthold Stoeger:
> On Donnerstag, 24. Mai 2018 22:46:30 CEST Gaetan Bisson wrote:
> > [2018-05-23 07:20:43 -1000] Gaetan Bisson:
> > > Oh, it's also there:
> > >   https://bugreports.qt.io/browse/QTBUG-67948
> > 
> > It turns out removing oldModel->deleteLater(); from DiveListView::reload()
> > avoids the segfault. See the discussion in the above bug report. However I
> > have no idea what the proper fix should be.
> 
> For one, we could delete it directly, c.f. attached patch.

There's no segfault with that patch.

Weird but good. :)

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

Re: Segfault with Qt-5.11.0

[Gaetan Bisson]

[2018-05-23 07:20:43 -1000] Gaetan Bisson:
> Oh, it's also there:
> 
>   https://bugreports.qt.io/browse/QTBUG-67948

It turns out removing oldModel->deleteLater(); from DiveListView::reload()
avoids the segfault. See the discussion in the above bug report. However I
have no idea what the proper fix should be.

Cheers.

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

Re: Segfault with Qt-5.11.0

[Gaetan Bisson]

[2018-05-23 07:12:45 -1000] Gaetan Bisson:
> [2018-05-23 10:28:52 -0300] Thiago Macieira:
> > On Wednesday, 23 May 2018 05:08:58 -03 Gaetan Bisson wrote:
> > > Any ideas how to debug this?
> > 
> > Can you valgrind? Without debug symbols in Qt it may be a little difficult 
> > to 
> > make sense of what we're seeing, but it might help.
> 
> Sure; see valgrind's log attached. The core dump is too big to send by
> email but I can find a way to get it to you if needed. Also, while I was
> asleep, Arch's Qt packager bisected the faulty commit to:
> 
>   
> http://code.qt.io/cgit/qt/qtbase.git/patch/?id=1c0fcbc887459d8963088309e83303eb1a7d2db0
>   
> Which I note is also suspected for other segfaults:
> 
>   https://github.com/lxqt/libfm-qt/issues/164
> 
> He has reported this issue there:
> 
>   https://bugreports.qt.io/browse/QTBUG-68427

Oh, it's also there:

https://bugreports.qt.io/browse/QTBUG-67948

Cheers.

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

Segfault with Qt-5.11.0

[Gaetan Bisson]

Dear all,

I'm getting a segfault when running Subsurface with Qt-5.11. It occurs
with both an old binary compiled against Qt-5.10 and a freshly rebuilt
binary. Note that building against Qt-5.11 requires fixing a couple of
headers, but that's unrelated:

https://github.com/Subsurface-divelog/subsurface/pull/1317

The segfault occurs whenever the dive list is nonempty. With a new
profile, just click on "Log" then "Add Dive" and then "Apply Changes" to
trigger it. Here's a backtrace:


Thread 1 "subsurface" received signal SIGSEGV, Segmentation fault.
0x705aa4d2 in QSortFilterProxyModel::parent(QModelIndex const&) const 
() from /usr/lib/libQt5Core.so.5
(gdb) bt
#0  0x705aa4d2 in QSortFilterProxyModel::parent(QModelIndex const&) 
const () at /usr/lib/libQt5Core.so.5
#1  0x7291f60a in QTreeView::drawRow(QPainter*, QStyleOptionViewItem 
const&, QModelIndex const&) const () at /usr/lib/libQt5Widgets.so.5
#2  0x72924e7f in QTreeView::drawTree(QPainter*, QRegion const&) const 
() at /usr/lib/libQt5Widgets.so.5
#3  0x729299f8 in QTreeView::paintEvent(QPaintEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#4  0x726a0058 in QWidget::event(QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#5  0x727467df in QFrame::event(QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#6  0x728c0b84 in QAbstractItemView::viewportEvent(QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#7  0x7292aa3c in QTreeView::viewportEvent(QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#8  0x705cf8db in 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () at 
/usr/lib/libQt5Core.so.5
#9  0x72660974 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() at /usr/lib/libQt5Widgets.so.5
#10 0x7266825b in QApplication::notify(QObject*, QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#11 0x705cfbc9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at /usr/lib/libQt5Core.so.5
#12 0x726989bc in QWidgetPrivate::sendPaintEvent(QRegion const&) () at 
/usr/lib/libQt5Widgets.so.5
#13 0x72699141 in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#14 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#15 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#16 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#17 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#18 0x72698f0d in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#19 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#20 0x72698f0d in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#21 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#22 0x72698f0d in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#23 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#24 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#25 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#26 0x72698f0d in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#27 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList 

Re: releases everywhere

[Gaetan Bisson]

[2017-12-07 18:35:43 -0600] Dirk Hohndel:
> Funny coincidence... I was just about done with writing the release 
> announcement post for Subsurface 4.7.5 when I got the notification that the 
> review of Subsurface-mobile-2.0.1 for iOS was completed.
> So today we actually managed to release a new version for ALL of our 
> platforms since I also pushed an update to Subsurface-mobile 2.0.1 for 
> Android this morning.

That's awesome! Thanks Dirk.

I always feel a bit silly bringing up trivial packaging issues but it
appears the "libdivecomputer-subsurface-branch-4.7.5.tgz" tarball is a
copy of the Subsurface source tree, not libdc. Could you push a new one?

Cheers.

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

Re: 4.7.1 released

[Gaetan Bisson]

[2017-10-22 11:18:20 -1000] Gaetan Bisson:
> Thanks for this new release! I'm ashamed I can't get subsurface-4.7.1 to
> compile against the new libdivecomputer-subsurface-branch tarball...

Ah, my mistake, I used the tarball from:


https://subsurface-divelog.org/downloads/libdivecomputer-subsurface-branch-4.7.1.tgz

Which looks nothing like the one github gives me for libdc's 4.7.1 tag
(probably what I should use instead).

Cheers.

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

Re: 4.7.1 released

[Gaetan Bisson]

Hi Dirk,

Thanks for this new release! I'm ashamed I can't get subsurface-4.7.1 to
compile against the new libdivecomputer-subsurface-branch tarball... I'm
getting errors like this:

In file included from /build/src/Subsurface-4.7.1/core/qt-ble.cpp:18:0:
/build/src/Subsurface-4.7.1/./core/qt-ble.h:57:25: error: 'dc_custom_io_t' was 
not declared in this scope
 dc_status_t qt_ble_open(dc_custom_io_t *io, dc_context_t *context, const char 
*name);
 ^~
/build/src/Subsurface-4.7.1/./core/qt-ble.h:57:25: note: suggested alternative: 
'dc_gasmix_t'
 dc_status_t qt_ble_open(dc_custom_io_t *io, dc_context_t *context, const char 
*name);
 ^~
 dc_gasmix_t
/build/src/Subsurface-4.7.1/./core/qt-ble.h:57:41: error: 'io' was not declared 
in this scope
 dc_status_t qt_ble_open(dc_custom_io_t *io, dc_context_t *context, const char 
*name);
 ^~
[...]

Where is dc_custom_io_t supposed to be defined?

Cheers.

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

Official upstream... or not?

[Gaetan Bisson]

Hi Dirk,

The GitHub project page for Subsurface says "This is NOT the official
upstream of Subsurface" with a link to that very same page. See:

https://github.com/Subsurface-divelog/subsurface

I find this statement slightly confusing. Is this not the official
upstream code repository?

Cheers.

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

Re: Segfault caused by "Hook qt model for country"

[Gaetan Bisson]

[2017-10-04 03:06:53 +0300] Lubomir I. Ivanov:
> something else i would try is to modify this near line 430 in
> divelistview.cpp, from:
> DiveTripModel *tripModel = new DiveTripModel(this);
> to:
> tripModel = new DiveTripModel(this);

Yay! With this modification all works perfectly. (No need to also apply
your earlier patch which puts columnWidthMap on the heap.)

Thanks so much.

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

Re: Segfault caused by "Hook qt model for country"

[Gaetan Bisson]

[2017-10-04 02:42:58 +0300] Lubomir I. Ivanov:
> Gaetan, can you please try applying the attached patch on the latest
> master for reference?

Sure. With that patch I get a segfault:

Thread 1 "subsurface" received signal SIGSEGV, Segmentation fault.
0x557ab79d in DiveTripModel::columnWidth(int) ()
(gdb) bt
#0  0x557ab79d in DiveTripModel::columnWidth(int) ()
#1  0x5571fb96 in DiveListView::setupUi() ()
#2  0x5571fdfe in DiveListView::reload(DiveTripModel::Layout, 
bool) ()
#3  0x5566168d in MainWindow::recreateDiveList() ()
#4  0x5566ab21 in MainWindow::refreshDisplay(bool) ()
#5  0x5566cb56 in MainWindow::loadFiles(QStringList) ()
#6  0x5565d425 in main ()

If I start with an empty subsurface profile then all is fine until I add
a dive to the list at which point the segfault happens.

Sorry I cannot help much more now. I'll try to clear some time tonight
(in about six hours) to try and actively investigate this...

Cheers.

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

Re: Segfault caused by "Hook qt model for country"

[Gaetan Bisson]

[2017-10-03 12:36:11 -1000] Gaetan Bisson:
> [2017-10-03 10:56:48 -0700] Dirk Hohndel:
> > On Mon, Oct 02, 2017 at 04:50:27PM -1000, Gaetan Bisson wrote:
> > > Hi,
> > > 
> > > I'm building the latest git snapshot of Subsurface on Arch Linux (we've
> > > got qt-5.9.1) and the latest commit "Hook qt model for country"
> > > (d5ab03ef4e84820f9530152dbf4ffc29dec6e652) causes a segfault.
> > > 
> > > Building goes well but then when running the binary I get:
> > > 
> > >   Thread 1 "subsurface" received signal SIGSEGV, Segmentation fault.
> > >   0x55721d87 in DiveListView::DiveListView(QWidget*) ()
> > >   (gdb) bt
> > >   #0  0x55721d87 in DiveListView::DiveListView(QWidget*) ()
> > >   #1  0x5566f07e in MainWindow::MainWindow() ()
> > >   #2  0x5566858d in init_ui() ()
> > >   #3  0x55666f9d in main ()
> > > 
> > > I've bisected this segfault to that precise commit. I have no idea how
> > > to debug this further but will be happy to help in any way I can.
> > 
> > Can you look at the disassembly at the crash and see if this might be
> > similar to what Lubomir just reported? The loop going way further than it
> > should?
> 
> Yes. I've got no segfault after applying Lubomir's pull request.

Though now, if the dive list is nonempty, the dive list widget shows
*only* the location column.

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

Re: Segfault caused by "Hook qt model for country"

[Gaetan Bisson]

[2017-10-03 10:56:48 -0700] Dirk Hohndel:
> On Mon, Oct 02, 2017 at 04:50:27PM -1000, Gaetan Bisson wrote:
> > Hi,
> > 
> > I'm building the latest git snapshot of Subsurface on Arch Linux (we've
> > got qt-5.9.1) and the latest commit "Hook qt model for country"
> > (d5ab03ef4e84820f9530152dbf4ffc29dec6e652) causes a segfault.
> > 
> > Building goes well but then when running the binary I get:
> > 
> > Thread 1 "subsurface" received signal SIGSEGV, Segmentation fault.
> > 0x55721d87 in DiveListView::DiveListView(QWidget*) ()
> > (gdb) bt
> > #0  0x55721d87 in DiveListView::DiveListView(QWidget*) ()
> > #1  0x5566f07e in MainWindow::MainWindow() ()
> > #2  0x5566858d in init_ui() ()
> > #3  0x55666f9d in main ()
> > 
> > I've bisected this segfault to that precise commit. I have no idea how
> > to debug this further but will be happy to help in any way I can.
> 
> Can you look at the disassembly at the crash and see if this might be
> similar to what Lubomir just reported? The loop going way further than it
> should?

Yes. I've got no segfault after applying Lubomir's pull request.

Thanks Lubomir!

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

Re: Segfault caused by "Hook qt model for country"

[Gaetan Bisson]

[2017-10-02 21:04:04 -0700] Dirk Hohndel:
> I'd consider master in "maybe not the best time to use it" state...

No problem. I can sure use an earlier snapshot for now. I'll let you
know if I'm still having this issue with master in a week or two.

Cheers.

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

Segfault caused by "Hook qt model for country"

[Gaetan Bisson]

Hi,

I'm building the latest git snapshot of Subsurface on Arch Linux (we've
got qt-5.9.1) and the latest commit "Hook qt model for country"
(d5ab03ef4e84820f9530152dbf4ffc29dec6e652) causes a segfault.

Building goes well but then when running the binary I get:

Thread 1 "subsurface" received signal SIGSEGV, Segmentation fault.
0x55721d87 in DiveListView::DiveListView(QWidget*) ()
(gdb) bt
#0  0x55721d87 in DiveListView::DiveListView(QWidget*) ()
#1  0x5566f07e in MainWindow::MainWindow() ()
#2  0x5566858d in init_ui() ()
#3  0x55666f9d in main ()

I've bisected this segfault to that precise commit. I have no idea how
to debug this further but will be happy to help in any way I can.

Cheers.

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

Re: Working Proof of Concept: "AppImage with everything", prepared on Arch, can download from D9 on CentOS

[Gaetan Bisson]

[2017-08-02 11:13:04 -0700] Dirk Hohndel:
> 
> > On Aug 2, 2017, at 10:07 AM, Gaetan Bisson <gae...@fenua.org> wrote:
> > 
> > [2017-08-02 08:30:33 -0700] Dirk Hohndel:
> >> That makes sense. We don't have a daily/test build for Arch. And that
> >> shouldn't be all that hard to do, anyway.
> > 
> > For information, myself and a few others use the subsurface-git package
> > from the AUR [1] which updates to the latest git snapshot whenever you
> > build it.
> > 
> > [1] https://aur.archlinux.org/packages/subsurface-git/
> 
> And this has made the change to build without Marble and use the
> new QtLocation maps instead?

Yes.

I maintain this package so whenever there's a shiny new feature
discussed on this list it gets enabled there relatively quickly.

Cheers.

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

Re: Working Proof of Concept: "AppImage with everything", prepared on Arch, can download from D9 on CentOS

[Gaetan Bisson]

[2017-08-02 08:30:33 -0700] Dirk Hohndel:
> That makes sense. We don't have a daily/test build for Arch. And that
> shouldn't be all that hard to do, anyway.

For information, myself and a few others use the subsurface-git package
from the AUR [1] which updates to the latest git snapshot whenever you
build it.

[1] https://aur.archlinux.org/packages/subsurface-git/

Cheers.

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

WorldMap gives DeletedApiProjectMapError

[Gaetan Bisson]

Hi,

I've tried making a new world map of my dive sites (File, Export,
Worldmap) but loading it in any browser gives: "Oops! Something went
wrong. This page didn't load Google Maps correctly. See the JavaScript
console for technical details."

And the console says: "Google Maps API error: DeletedApiProjectMapError
https://developers.google.com/maps/documentation/javascript/error-messages#deleted-api-project-map-error;
So it would appear our "API project may have been deleted from the
Google API Console."

Does anyone know how to fix this?

Cheers.

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

Re: [PATCH 6/4] Fix another cylinder pressure plotting special case

[Gaetan Bisson]

[2017-07-30 11:22:34 -0700] Linus Torvalds:
> On Sun, Jul 30, 2017 at 10:51 AM, Linus Torvalds
>  wrote:
> >
> > So I think the code now does exactly the right thing for your case. Except
> > for the equipment tab side, which doesn't show your two unused cylinders,
> > even though you filled in information for them. But that looks like a
> > pre-existing bug and probably has nothing to do with the recent pressure
> > graph changes.
> 
> Oh. And that's not a bug, it's a "feature".
> 
> We have a "display_unused_tanks" preference setting, which disables
> showing of tanks that aren't actively used during the dive.
> 
> So the crazy code will initially show them as you add them (because it
> has logic to always show manually added cylinders), but then as you
> read the xml file again, it will stop showing them, because now they
> are no longer manually added, and their gas use indicates they weren't
> used during the dive.
> 
> That's not a great feature.
> 
> This attached patch may or may not be an improvement. Dirk?
> 
> The new logic is basically:
> 
>  - if the cylinder is "used", it is always shown (so gas pressure has
> changed, or we have gas switch events to it, or it's the first gas and
> we had no switches away from it or whatever)
> 
>  - if the cylinder has no data at all, we don't show it
> 
>  - if it has pressure information - even if that pressure information
> indicates that it wasn't used - it's shown
> 
>  - I left the "manually added" case
> 
>  - if it's not used, and has no pressure information, but does have a
> type name and size, we fall back to the "prefs.display_unused_tanks"
> thing.
> 
> I personally think this is an improvement, and it now shows all four
> cylinders that Gaetan had on his CCR dive, even if the bailout
> cylinders weren't actually used.
> 
> Gaetan had filled in cylinder pressures and everything, I think we
> should show them by default.

I had indeed ticked the "show unused cylinders" option specifically for
the unused bailout case, but then I had to manually delete all the
virtual cylinders my OSTC3 reported after each dive... And I hadn't
realized life could be better!

Thanks a lot for this patch, I think the new logic makes a lot of sense.

Cheers.

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

Re: [PATCH] Profile support for multiple concurrent pressure sensors

[Gaetan Bisson]

[2017-07-30 10:32:56 -0700] Linus Torvalds:
> Yup, that was it. The attached patch fixes it.

Thanks so much!

> The patch *does* show something a bit odd, though. Your second dive in that
> XML file you sent actually has gas data for *four* cylinders:
> 
>   'Steel 2L' start='190.0 bar' end='110.0 bar'
>   'Steel 2L' o2='100.0%' start='180.0 bar' end='90.0 bar'
>   'Steel 6L' o2='32.0%' start='160.0 bar' end='160.0 bar'
>   'Steel 6L' o2='50.0%' start='180.0 bar' end='180.0 bar'
> 
> but you don't actually have any gas change events for that dive.

The first two are the small O2 and air cylinders in my rebreather, the
other two are EAN32 and EAN50 bailouts which I took with me on the dive
but did not end up using. So it looks good to me, but is there some way
I should be explicitly tagging my CCR cylinders and/or my bailout
cylinders as such to clear up the confusion?

Cheers.

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

[PATCH] libdc: export new symbol, needed for subsurface

[Gaetan Bisson]

Hi,

Since the dc_context_set_custom_serial is now being used in subsurface,
libdc must export it for dynamically-linked builds to work. See the
attached patch.

Cheers.

-- 
Gaetan
>From a9b95afbead3fd975adc71ff5a3a1c2d43d0d5d7 Mon Sep 17 00:00:00 2001
From: Gaetan Bisson <bis...@archlinux.org>
Date: Sat, 17 Sep 2016 18:02:05 -1000
Subject: [PATCH] export new symbol, needed by subsurface

Signed-off-by: Gaetan Bisson <bis...@archlinux.org>
---
 src/libdivecomputer.symbols | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/libdivecomputer.symbols b/src/libdivecomputer.symbols
index 347db27..da34c2a 100644
--- a/src/libdivecomputer.symbols
+++ b/src/libdivecomputer.symbols
@@ -21,6 +21,7 @@ dc_context_new
 dc_context_free
 dc_context_set_loglevel
 dc_context_set_logfunc
+dc_context_set_custom_serial
 
 dc_iterator_next
 dc_iterator_free
-- 
2.9.3

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

Re: Bug 971

[Gaetan Bisson]

[2016-08-11 00:42:35 +0200] Robert Helling:
> sorry if I got this wrong. He says he uses manjaro. I had never heard of that 
> and googled where I found that it’s Arch based, where I (erroneously) stopped 
> reading and concluded that it must be you.

I see.

Manjaro is essentially one person that took Arch, changed the name, and
messed with anything they felt like, often creating subtle issues in the
process. I would not recommend it, and it is definitely not supported by
Arch Linux.

The official subsurface package in Arch switched to Qt5 a year and a
half ago. So what a Qt4 build is doing in Manjaro, I don't know...

Cheers.

-- 
Gaetan


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

Re: Bug 971

[Gaetan Bisson]

[2016-08-10 23:08:22 +0200] Robert Helling:
> you are the maintainer of the subsurface package in Arch Linux. Could you 
> please have a look at this. It seems, there subsurface can be run with Qt 4 
> and that causes problems.

Subsurface is built against Qt5 in Arch Linux (and the custom versions
of marble and libdc). But I see no mention of Arch in the bug report.

It seems the reporter uses Fedora instead.

Cheers.

-- 
Gaetan


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

Re: missing ui_mainwindow.h?

[Gaetan Bisson]

Thanks Dirk and Robert,

So it turns out the issue is that I'm building with `make -j2` (in fact,
-j1 also exhibits the issue) and it goes away with `make -j4 like the
build script does. You can imagine what happens...

Apologies for not proposing a patch; I really know nothing about cmake.

Cheers.

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

missing ui_mainwindow.h?

[Gaetan Bisson]

Hi,

When building the latest git snapshot of subsurface on a
run-off-the-mill Linux desktop I get:


[ 28%] Building CXX object 
qt-models/CMakeFiles/subsurface_models.dir/filtermodels.cpp.o
In file included from 
/build/subsurface-git/src/subsurface/qt-models/filtermodels.cpp:8:0:
/build/subsurface-git/src/subsurface/./desktop-widgets/mainwindow.h:16:27: 
fatal error: ui_mainwindow.h: No such file or directory
 #include "ui_mainwindow.h"
   ^
compilation terminated.
make[2]: *** [qt-models/CMakeFiles/subsurface_models.dir/build.make:159: 
qt-models/CMakeFiles/subsurface_models.dir/filtermodels.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:594: 
qt-models/CMakeFiles/subsurface_models.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs


There's no ui_mainwindow.h in the source tree. Is that header file
supposed to be automatically generated in some way?

Cheers.

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

Re: Compiling libdivecomputer-subsurface-branch-4.5.4

[Gaetan Bisson]

[2016-03-22 10:34:06 -0700] Dirk Hohndel:
> That's my fault. Since we really build libdivecomputer only to get the 
> library, I didn't bother
> to change the sample app to deal with our changes to the API.
> 
> The simple fix is to pass "--disable-examples" to the configure call
> 
> I'll add a change to our branch that makes that the default (so you'd have to 
> manually
> enable the examples to build them and subsequently run into this problem.
> 
> I'm planning to do a 4.5.5 shortly which will also contain this fix in the 
> corresponding
> libdivecomputer version - this will include the latest libdivecomputer 
> changes with
> support for a few more dive computers as well.
> 
> Sorry for the complications - I ran into this in my own builds and just 
> changed
> the call to configure instead of changing the default behavior which would 
> have 
> been a much better solution.

No worries. Thanks for the explanation. I'll disable the example
binaries as you suggest until 4.5.5 is ready. Cheers!

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

Compiling libdivecomputer-subsurface-branch-4.5.4

[Gaetan Bisson]

Hi,

I'm trying to build libdivecomputer-subsurface-branch-4.5.4 from the
tarball. Running `autoreconf --install` and `./configure` gives a fairly
normal output. Then, `make` spits:


Making all in examples
  CC   common.o
  CC   dctool.o
  CC   dctool_help.o
  CC   dctool_version.o
  CC   dctool_list.o
  CC   dctool_download.o
  CC   dctool_dump.o
  CC   dctool_parse.o
dctool_parse.c: In function ‘parse’:
dctool_parse.c:85:8: error: too few arguments to function 
‘suunto_d9_parser_create’
   rc = suunto_d9_parser_create (, context, model);
^
In file included from ../include/libdivecomputer/suunto.h:29:0,
 from dctool_parse.c:37:
../include/libdivecomputer/suunto_d9.h:45:1: note: declared here
 suunto_d9_parser_create (dc_parser_t **parser, dc_context_t *context, unsigned 
int model, unsigned int serial);
 ^
dctool_parse.c:117:9: error: too few arguments to function 
‘oceanic_atom2_parser_create’
rc = oceanic_atom2_parser_create (, context, model);
 ^
In file included from ../include/libdivecomputer/oceanic.h:25:0,
 from dctool_parse.c:40:
../include/libdivecomputer/oceanic_atom2.h:46:1: note: declared here
 oceanic_atom2_parser_create (dc_parser_t **parser, dc_context_t *context, 
unsigned int model, unsigned int serial);
 ^
dctool_parse.c:130:8: error: too few arguments to function 
‘hw_ostc_parser_create’
   rc = hw_ostc_parser_create (, context, 0);
^
In file included from ../include/libdivecomputer/hw.h:25:0,
 from dctool_parse.c:42:
../include/libdivecomputer/hw_ostc.h:68:1: note: declared here
 hw_ostc_parser_create (dc_parser_t **parser, dc_context_t *context, unsigned 
int serial, unsigned int frog);
 ^
dctool_parse.c:134:8: error: too few arguments to function 
‘hw_ostc_parser_create’
   rc = hw_ostc_parser_create (, context, 1);
^
In file included from ../include/libdivecomputer/hw.h:25:0,
 from dctool_parse.c:42:
../include/libdivecomputer/hw_ostc.h:68:1: note: declared here
 hw_ostc_parser_create (dc_parser_t **parser, dc_context_t *context, unsigned 
int serial, unsigned int frog);
 ^
dctool_parse.c:147:8: error: too few arguments to function 
‘shearwater_predator_parser_create’
   rc = shearwater_predator_parser_create (, context);
^
In file included from ../include/libdivecomputer/shearwater.h:25:0,
 from dctool_parse.c:46:
../include/libdivecomputer/shearwater_predator.h:44:1: note: declared here
 shearwater_predator_parser_create (dc_parser_t **parser, dc_context_t 
*context, unsigned int serial);
 ^
dctool_parse.c:150:8: error: too few arguments to function 
‘shearwater_petrel_parser_create’
   rc = shearwater_petrel_parser_create (, context);
^
In file included from ../include/libdivecomputer/shearwater.h:26:0,
 from dctool_parse.c:46:
../include/libdivecomputer/shearwater_petrel.h:41:1: note: declared here
 shearwater_petrel_parser_create (dc_parser_t **parser, dc_context_t *context, 
unsigned int serial);
 ^
Makefile:447: recipe for target 'dctool_parse.o' failed
make[2]: *** [dctool_parse.o] Error 1
Makefile:470: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
Makefile:379: recipe for target 'all' failed
make: *** [all] Error 2


Is this a bug or a feature? :)

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

Re: 4.5.2

[Gaetan Bisson]

[2015-11-07 14:05:55 -0800] Dirk Hohndel:
> Just a quick heads up. Heinrichs Weikamp surprised us with a firmware change 
> that breaks downloading from their dive computers. It would have been nice 
> had we known this was coming, but it is what it is. I decided to merge Jef's 
> latest updates to libdivecomputer (YAY Jef!!!) into our branch and respin 
> Subsurface as 4.5.2 using the updated libdivecomputer.

So there are 4.5.2 tarballs for libdivecomputer-subsurface-branch and
marble-subsurface-branch but should still use the 4.5.1 tarball for
subsurface itself? Or will you be releasing a new Subsurface-4.5.2.tgz
too, even if the only change it has is a bump in the version number?

Cheers.

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

Re: new website - or "jet lag is good"

[Gaetan Bisson]

[2015-10-10 23:01:15 -0700] Dirk Hohndel:
> Please go to http://ssrftest.subsurface-divelog.org 
>  and let me know what you think.

Wow, great work, that really looks awesome.

The only thing I noted is that we have two redundant social media
banners (one in "top-header" and the other in "footer-bottom"); perhaps
the top one could be removed so page contents get bumped up?

Cheers.

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

Re: [PATCH 1/1] Use ~/.subsurface as default directory on Linux

[Gaetan Bisson]

[2015-10-12 00:20:14 +0300] Lubomir I. Ivanov:
> i would say -1 for $XDG_DATA_HOME as that doesn't seem to be
> established very well, yet.
> but $HOME/.local/share/subsurface is less intrusive than ~/.subsurface
> IMHO, so +1 to that.

As far as I understand the XDG specs:
- the cloud storage cache should go under ~/.cache/Subsurface/
- the configuration file should go under ~/.config/Subsurface/
- some other things should go under ~/.local/share/Subsurface/

To me, that really scatters user data over many directories for
little-to-no benefit. Instead, I'd like an app called Subsurface to
simply write its user data under ~/.subsurface/: that's a unique
directory for me to symlink, backup, or rename, for instance in case
there's an issue I want to debug with a fresh profile.

But that's just my two cents.

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

[PATCH 1/1] Use ~/.subsurface as default directory on Linux

[Gaetan Bisson]

Hi guys,

I only just noticed that cloud storage now uses (and automatically
creates) the ~/subsurface directory. Perhaps I missed some discussion
about it, but I would much prefer a name that starts with a dot. Does
the attached patch makes sense to you?

Cheers.

-- 
Gaetan
>From a0805d5143410afd52b27f3a7792e3ada07c90e4 Mon Sep 17 00:00:00 2001
From: Gaetan Bisson <bis...@archlinux.org>
Date: Sat, 10 Oct 2015 19:24:09 -1000
Subject: [PATCH 1/1] Use ~/.subsurface as default directory on Linux

This is more discreet than ~/subsurface (the previous default) and
follows a well-established tradition.

Signed-off-by: Gaetan Bisson <bis...@archlinux.org>
---
 linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux.c b/linux.c
index d23af1a..d4131c7 100644
--- a/linux.c
+++ b/linux.c
@@ -53,7 +53,7 @@ static const char *system_default_path_append(const char *append)
 	const char *home = getenv("HOME");
 	if (!home)
 		home = "~";
-	const char *path = "/subsurface";
+	const char *path = "/.subsurface";
 
 	int len = strlen(home) + strlen(path) + 1;
 	if (append)
-- 
2.6.1

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

Re: cmake -DMARBLE_INCLUDE_DIR broken?

[Gaetan Bisson]

Hi again,

So I do not change the dive site at all (just fiddle with the notes),
and when I click "Apply Changes", in MainTab::updateDiveSite(), the
pickedUuid variable is 16777215 == 2^24-1. I'm not sure how that
happens, but obviously it should be zero in order to be caught by the
test you added.

Cheers.

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

Re: cmake -DMARBLE_INCLUDE_DIR broken?

[Gaetan Bisson]

[2015-09-23 20:10:35 -1000] Gaetan Bisson:
> So I do not change the dive site at all (just fiddle with the notes),
> and when I click "Apply Changes", in MainTab::updateDiveSite(), the
> pickedUuid variable is 16777215 == 2^24-1. I'm not sure how that
> happens, but obviously it should be zero in order to be caught by the
> test you added.

Ha! The currUuid variable was never initialized...

Patch attached.

-- 
Gaetan
>From d5fd492439ada38d795b703d78f8a4384ace3a08 Mon Sep 17 00:00:00 2001
From: Gaetan Bisson <bis...@archlinux.org>
Date: Wed, 23 Sep 2015 21:12:18 -1000
Subject: [PATCH 1/1] Initialize currUuid

Signed-off-by: Gaetan Bisson <bis...@archlinux.org>
---
 qt-ui/locationinformation.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/qt-ui/locationinformation.cpp b/qt-ui/locationinformation.cpp
index 6e6db0b..213d63b 100644
--- a/qt-ui/locationinformation.cpp
+++ b/qt-ui/locationinformation.cpp
@@ -360,6 +360,7 @@ bool DiveLocationModel::setData(const QModelIndex& index, const QVariant& value,
 DiveLocationLineEdit::DiveLocationLineEdit(QWidget *parent) : QLineEdit(parent),
 	proxy(new DiveLocationFilterProxyModel()), model(new DiveLocationModel()), view(new DiveLocationListView())
 {
+	currUuid = 0;
 	location_line_edit = this;
 
 	proxy->setSourceModel(model);
-- 
2.5.3

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

Re: cmake -DMARBLE_INCLUDE_DIR broken?

[Gaetan Bisson]

[2015-09-23 14:58:43 -1000] Gaetan Bisson:
>   cmake \
>   -DCMAKE_BUILD_TYPE=Release \
>   -DCMAKE_INSTALL_PREFIX=/usr \
>   -DMARBLE_INCLUDE_DIR='/usr/include/subsurface' \
>   -DUSE_LIBGIT23_API=1 \
>   .

I had missed this error message from cmake:

CMake Warning:
  Manually-specified variables were not used by the project:

MARBLE_INCLUDE_DIR

Is this expected? If yes, what would be the recommended way to specify
another path for marble's header files? I note that MARBLE_INCLUDE_DIR
is still used in build.sh.

Cheers.

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

Re: cmake -DMARBLE_INCLUDE_DIR broken?

[Gaetan Bisson]

[2015-09-23 20:04:56 -0700] Dirk Hohndel:
> On Wed, Sep 23, 2015 at 07:58:02PM -0700, Dirk Hohndel wrote:
> > On Wed, Sep 23, 2015 at 04:36:45PM -1000, Gaetan Bisson wrote:
> > > [2015-09-23 15:53:59 -1000] Gaetan Bisson:
> > > > Ah, that second issue goes away (and subsurface builds fine) when I add
> > > > the cmake option -DMARBLE_LIBRARIES=/usr/lib/libssrfmarblewidget.so .
> > > 
> > > Oh, now I'm getting a segfault when I edit any dive and click "Apply 
> > > Changes".
> > 
> > Hehe, I can confirm that. I was so busy testing the location handling that
> > I apparently didn't notice that something that went in today broke basic
> > editing.
> > 
> > I'll look into it.
> 
> OK, I think I fixed this. Please try again with the latest master.

Thanks so much for looking into this. Unfortunately it seems the bug is
still there with the latest master. I'll try to debug this and send a
more helpful report.

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

Re: cmake -DMARBLE_INCLUDE_DIR broken?

[Gaetan Bisson]

[2015-09-23 15:53:59 -1000] Gaetan Bisson:
> Ah, that second issue goes away (and subsurface builds fine) when I add
> the cmake option -DMARBLE_LIBRARIES=/usr/lib/libssrfmarblewidget.so .

Oh, now I'm getting a segfault when I edit any dive and click "Apply Changes".

Program received signal SIGSEGV, Segmentation fault.
0x00627ca5 in copy_dive_site ()
(gdb) bt
#0  0x00627ca5 in copy_dive_site ()
#1  0x00594711 in MainTab::updateDiveSite(int) ()
#2  0x0059bb2d in MainTab::acceptChanges() ()
#3  0x0055a1dd in ?? ()
#4  0x7142bfea in QMetaObject::activate(QObject*, int, int, void**) () 
from /usr/lib/libQt5Core.so.5
#5  0x723dd3d2 in QAction::triggered(bool) () from 
/usr/lib/libQt5Widgets.so.5
#6  0x723df878 in QAction::activate(QAction::ActionEvent) () from 
/usr/lib/libQt5Widgets.so.5
#7  0x724e5900 in ?? () from /usr/lib/libQt5Widgets.so.5
#8  0x724e5a34 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () 
from /usr/lib/libQt5Widgets.so.5
#9  0x725aa17a in QToolButton::mouseReleaseEvent(QMouseEvent*) () from 
/usr/lib/libQt5Widgets.so.5
#10 0x72429f08 in QWidget::event(QEvent*) () from 
/usr/lib/libQt5Widgets.so.5
#11 0x725aa259 in QToolButton::event(QEvent*) () from 
/usr/lib/libQt5Widgets.so.5
#12 0x723e700c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/libQt5Widgets.so.5
#13 0x723ecbe9 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/libQt5Widgets.so.5
#14 0x713fd89b in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/libQt5Core.so.5
#15 0x723ebaf2 in QApplicationPrivate::sendMouseEvent(QWidget*, 
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) () from 
/usr/lib/libQt5Widgets.so.5
#16 0x7244474b in ?? () from /usr/lib/libQt5Widgets.so.5
#17 0x72446cfb in ?? () from /usr/lib/libQt5Widgets.so.5
#18 0x723e700c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/libQt5Widgets.so.5
#19 0x723ec4e6 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/libQt5Widgets.so.5
#20 0x713fd89b in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/libQt5Core.so.5
#21 0x71c0cc81 in 
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
 () from /usr/lib/libQt5Gui.so.5
#22 0x71c0e955 in 
QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
 () from /usr/lib/libQt5Gui.so.5
#23 0x71bf3e08 in 
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
 () from /usr/lib/libQt5Gui.so.5
#24 0x7fffe22fb9f0 in ?? () from /usr/lib/libQt5XcbQpa.so.5
#25 0x7fffec9ad9fd in g_main_context_dispatch () from 
/usr/lib/libglib-2.0.so.0
#26 0x7fffec9adce0 in ?? () from /usr/lib/libglib-2.0.so.0
#27 0x7fffec9add8c in g_main_context_iteration () from 
/usr/lib/libglib-2.0.so.0
#28 0x7145423f in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/libQt5Core.so.5
#29 0x713fb26a in 
QEventLoop::exec(QFlags) () from 
/usr/lib/libQt5Core.so.5
#30 0x7140320c in QCoreApplication::exec() () from 
/usr/lib/libQt5Core.so.5
#31 0x004926c0 in main ()

I'm running the latest git (commit 6ee2a44).

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

Re: cmake -DMARBLE_INCLUDE_DIR broken?

[Gaetan Bisson]

[2015-09-23 14:58:43 -1000] Gaetan Bisson:
> linking fails with:
> 
>   [100%] Linking CXX executable subsurface
>   libsubsurface_interface.a(subsurface_interface_automoc.cpp.o): In 
> function `GlobeGPS::qt_metacall(QMetaObject::Call, int, void**)':
>   /build/subsurface-git/src/subsurface/moc_globe.cpp:161: undefined 
> reference to `Marble::MarbleWidget::qt_metacall(QMetaObject::Call, int, 
> void**)'
>   libsubsurface_interface.a(subsurface_interface_automoc.cpp.o): In 
> function `GlobeGPS::qt_metacast(char const*)':
>   /build/subsurface-git/src/subsurface/moc_globe.cpp:156: undefined 
> reference to `Marble::MarbleWidget::qt_metacast(char const*)'
>   libsubsurface_interface.a(subsurface_interface_automoc.cpp.o): In 
> function `GlobeGPS::~GlobeGPS()':
>   /build/subsurface-git/src/subsurface/qt-ui/globe.h:20: undefined 
> reference to `Marble::MarbleWidget::~MarbleWidget()'
>   libsubsurface_interface.a(subsurface_interface_automoc.cpp.o): In 
> function `GlobeGPS::~GlobeGPS()':
>   /build/subsurface-git/src/subsurface/qt-ui/globe.h:20: undefined 
> reference to `Marble::MarbleWidget::~MarbleWidget()'
>   
> libsubsurface_interface.a(subsurface_interface_automoc.cpp.o):(.data.rel.ro._ZTI8GlobeGPS[_ZTI8GlobeGPS]+0x10):
>  undefined reference to `typeinfo for Marble::MarbleWidget'
>   ...

Ah, that second issue goes away (and subsurface builds fine) when I add
the cmake option -DMARBLE_LIBRARIES=/usr/lib/libssrfmarblewidget.so .

Cheers.

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

cmake -DMARBLE_INCLUDE_DIR broken?

[Gaetan Bisson]

Hi,

I've just built and installed today's git snapshot of our marble branch.
Now I'm trying to build today's git snapshot of subsurface against it.
However, invoking cmake as:

cmake \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=/usr \
-DMARBLE_INCLUDE_DIR='/usr/include/subsurface' \
-DUSE_LIBGIT23_API=1 \
.

Gives me:

[ 80%] Building CXX object 
CMakeFiles/subsurface_interface.dir/qt-ui/globe.cpp.o
In file included from 
/build/subsurface-git/src/subsurface/qt-ui/globe.cpp:1:0:
/build/subsurface-git/src/subsurface/qt-ui/globe.h:7:33: fatal error: 
marble/MarbleWidget.h: No such file or directory
compilation terminated.
CMakeFiles/subsurface_interface.dir/build.make:230: recipe for target 
'CMakeFiles/subsurface_interface.dir/qt-ui/globe.cpp.o' failed
make[2]: *** [CMakeFiles/subsurface_interface.dir/qt-ui/globe.cpp.o] 
Error 1

But the file /usr/include/subsurface/marble/MarbleWidget.h is actually
there, so it seems the -DMARBLE_INCLUDE_DIR option does not get passed
on to whatever compiles globe.cpp.

Hum. And when I replace:

#include http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Artifacts with VPM-B ceiling on level changes

[Gaetan Bisson]

[2015-08-30 07:20:18 +1000] Rick Walsh:
 Good morning,
 
 On 30 Aug 2015 7:12 am, Robert C. Helling hell...@atdotde.de wrote:
 
  Gaetan,
 
  On 28 Aug 2015, at 05:31, Gaetan Bisson bis...@archlinux.org wrote:
 
  I've noticed what looks to me like artifacts regarding the ceiling VPM
  calculates for multilevel dives. See the attached screenshot.
 
  Basically, during manually entered ascent segments, the calculated
  ceiling becomes deeper as the diver goes shallower...
 
  It might just be a well-known VPM feature but I still thought I would
  ask here if anyone knows what is going on.
 
 
  I figured out the origin of this „feature“: The ceilings we plot are
 based on the allowed gradient (tissue pressure minus ambient pressure) of
 the tissue. This gradient is depth dependent (according to the „Boyle
 compensation which says that (gradient + ambient pressure)/gradient^3 must
 be constant during the ascent. When we plot, we use the gradient for the
 current depth but that shrinks as soon as we ascend and so the ceiling
 comes down upon the ascent. We should better plot a ceiling defined as the
 depth where the Boyle compensated gradient is the actual gradient and then
 the ceiling would no longer be depth dependent. But this requires some more
 work, which I have to postpone to tomorrow.
 
 I no longer see the feature. I think it was the sixth patch in the series
 that got rid of it.

Thanks so much to both of you.

Rick, I still seem to see the artifacts with latest master ( d22a135);
see attached. Should that not include the commit you refer to?

Of course, in light of Robert's explanation, it might not be worth
getting rid of these: we are potting the model data faithfully and it's
just how it works. We do not really have to work out something more
convoluted to plot just so as to make VPM-B look nicer.

Cheers.

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

Artifacts with VPM-B ceiling on level changes

[Gaetan Bisson]

Dear list,

I've noticed what looks to me like artifacts regarding the ceiling VPM
calculates for multilevel dives. See the attached screenshot.

Basically, during manually entered ascent segments, the calculated
ceiling becomes deeper as the diver goes shallower...

It might just be a well-known VPM feature but I still thought I would
ask here if anyone knows what is going on.

Cheers.

P.S. I'm running the latest git master (commit 4360cee).

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

Re: Ctrl-+ and Qt5.5

[Gaetan Bisson]

[2015-07-19 17:06:48 +0300] Claudiu Olteanu:
 I have a Fedora 22 with Qt 5.5.0 and the shortcut is working.
 Subsurface version: 4.4.2-1040-g5cbbff008411c322.

It might be related to this patch, then:


https://projects.archlinux.org/svntogit/packages.git/tree/trunk/keypad-shortcuts.patch?h=packages/qt5

I'll ask our Qt maintainer.

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

[PATCH 1/1] Add new functions to list of exported symbols

[Gaetan Bisson]

Hi Dirk,

I'm shamelessly bumping my proposed patch to libdc/Subsurface-testing
from earlier, this time as a thread-starter with [PATCH] in the
Subject... :)

Cheers.

-- 
Gaetan
From 8e2c23c1191144ce9355569d3e15ea84ec5a8b89 Mon Sep 17 00:00:00 2001
From: Gaetan Bisson bis...@archlinux.org
Date: Wed, 8 Jul 2015 07:14:50 -1000
Subject: [PATCH 1/1] Add new functions to list of exported symbols

This is required in order to build those new public functions into the
shared library.

Signed-off-by: Gaetan Bisson bis...@archlinux.org
---
 src/libdivecomputer.symbols | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/libdivecomputer.symbols b/src/libdivecomputer.symbols
index 562099d..0cef199 100644
--- a/src/libdivecomputer.symbols
+++ b/src/libdivecomputer.symbols
@@ -82,6 +82,9 @@ dc_device_set_events
 dc_device_set_fingerprint
 dc_device_write
 
+dc_serial_init
+dc_device_custom_open
+
 cressi_edy_device_open
 cressi_leonardo_device_open
 mares_nemo_device_open
-- 
2.4.5

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

Re: Linking error with recent libdc

[Gaetan Bisson]

[2015-07-08 06:06:07 -0700] Dirk Hohndel:
 On Tue, Jul 07, 2015 at 08:51:52PM -1000, Gaetan Bisson wrote:
  As I said in my reply to Jef's message, the build system issue I had
  was throwing away the static library.
 
 Ah, that explains it. We always link statically against libdivecomputer on
 all the platforms that I build binaries for.
 
 Arch is the one platform that builds their own that tracks master.

I see.

Would you be happy to apply the attached patch to our branch?

Cheers.

-- 
Gaetan
From 8e2c23c1191144ce9355569d3e15ea84ec5a8b89 Mon Sep 17 00:00:00 2001
From: Gaetan Bisson bis...@archlinux.org
Date: Wed, 8 Jul 2015 07:14:50 -1000
Subject: [PATCH 1/1] Add new functions to list of exported symbols

This is required in order to build those new public functions into the
shared library.

Signed-off-by: Gaetan Bisson bis...@archlinux.org
---
 src/libdivecomputer.symbols | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/libdivecomputer.symbols b/src/libdivecomputer.symbols
index 562099d..0cef199 100644
--- a/src/libdivecomputer.symbols
+++ b/src/libdivecomputer.symbols
@@ -82,6 +82,9 @@ dc_device_set_events
 dc_device_set_fingerprint
 dc_device_write
 
+dc_serial_init
+dc_device_custom_open
+
 cressi_edy_device_open
 cressi_leonardo_device_open
 mares_nemo_device_open
-- 
2.4.5

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

Re: Linking error with recent libdc

[Gaetan Bisson]

[2015-07-08 08:40:04 +0200] Jef Driesen:
 On 2015-07-08 07:13, Gaetan Bisson wrote:
 [2015-07-07 21:45:49 -0700] Dirk Hohndel:
 On Tue, Jul 07, 2015 at 05:59:00PM -1000, Gaetan Bisson wrote:
  Linking CXX executable subsurface
  libsubsurface_corelib.a(libdivecomputer.c.o): In function 
  `do_libdivecomputer_import':
  /build/subsurface-git/src/subsurface/libdivecomputer.c:932: undefined 
  reference to `dc_device_custom_open'
  libsubsurface_corelib.a(qtserialbluetooth.cpp.o): In function 
  `dc_serial_qt_open':
  /build/subsurface-git/src/subsurface/qtserialbluetooth.cpp:232: undefined 
  reference to `dc_serial_init'
  collect2: error: ld returned 1 exit status
  CMakeFiles/subsurface.dir/build.make:281: recipe for target 'subsurface' 
  failed
 
 So it's linking against the wrong libdivecomputer.
 
 So it seems I am building against the right one.
 
 Except the subsurface-libdc-git package I have built (from the proper
 sources) contains references to, say, dc_device_custom_open in its
 header files but not in the shared library...
 
 Is there anything new (dependency or otherwise) needed to properly build
 libdc/Subsurface-testing? Or perhaps my build karma is not doing well...
 
 I suspect the problem is that these functions are not listed in the
 src/libdivecomputer.symbols file. Only the functions that are listed there
 are exported in the shared library.

Right!

I was just noticing that if I do not throw away the static library the
linker indeed finds those functions there. The error only happens when
linking against the shared library.

Thanks.

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

Re: Linking error with recent libdc

[Gaetan Bisson]

[2015-07-07 20:35:14 -1000] Gaetan Bisson:
 [2015-07-07 20:21:49 -1000] Gaetan Bisson:
  Building subsurface master against that still fails for me.
 
 So things work as expected if I compile libdc without build flags.
 
 Our build system uses:
 
 CPPFLAGS=-D_FORTIFY_SOURCE=2
 CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong 
 --param=ssp-buffer-size=4
 CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong 
 --param=ssp-buffer-size=4
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro
 
 And apparently one of them makes libdc unhappy... I'll narrow it down
 and report back.

Forget that.

As I said in my reply to Jef's message, the build system issue I had
was throwing away the static library.

Cheers.

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

Re: Linking error with recent libdc

[Gaetan Bisson]

[2015-07-07 20:21:49 -1000] Gaetan Bisson:
 Building subsurface master against that still fails for me.

So things work as expected if I compile libdc without build flags.

Our build system uses:

CPPFLAGS=-D_FORTIFY_SOURCE=2
CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong 
--param=ssp-buffer-size=4
CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong 
--param=ssp-buffer-size=4
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro

And apparently one of them makes libdc unhappy... I'll narrow it down
and report back.

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

Re: Linking error with recent libdc

[Gaetan Bisson]

[2015-07-07 21:45:49 -0700] Dirk Hohndel:
 On Tue, Jul 07, 2015 at 05:59:00PM -1000, Gaetan Bisson wrote:
  Linking CXX executable subsurface
  libsubsurface_corelib.a(libdivecomputer.c.o): In function 
  `do_libdivecomputer_import':
  /build/subsurface-git/src/subsurface/libdivecomputer.c:932: undefined 
  reference to `dc_device_custom_open'
  libsubsurface_corelib.a(qtserialbluetooth.cpp.o): In function 
  `dc_serial_qt_open':
  /build/subsurface-git/src/subsurface/qtserialbluetooth.cpp:232: undefined 
  reference to `dc_serial_init'
  collect2: error: ld returned 1 exit status
  CMakeFiles/subsurface.dir/build.make:281: recipe for target 'subsurface' 
  failed
 
 So it's linking against the wrong libdivecomputer.

So it seems I am building against the right one.

Except the subsurface-libdc-git package I have built (from the proper
sources) contains references to, say, dc_device_custom_open in its
header files but not in the shared library...

Is there anything new (dependency or otherwise) needed to properly build
libdc/Subsurface-testing? Or perhaps my build karma is not doing well...

Cheers.

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

Custom libdc update

[Gaetan Bisson]

Hi,

Would it be possible to merge the recent changes made to upstream
libdivecomputer [1] into Subsurface's custom libdc [2]?

[1] http://git.libdivecomputer.org/?p=libdivecomputer.git
[2] http://git.subsurface-divelog.org/?p=libdc.git;a=summary

It looks like a straightforward merge, but please let me know if there
is anything I could do to help; I would be happy to.

Cheers.

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

Re: Custom libdc update

[Gaetan Bisson]

[2015-06-14 21:08:22 -0700] Dirk Hohndel:
 On Sun, Jun 14, 2015 at 08:58:10PM -0700, Dirk Hohndel wrote:
  On Sun, Jun 14, 2015 at 05:33:35PM -1000, Gaetan Bisson wrote:
   
   Would it be possible to merge the recent changes made to upstream
   libdivecomputer [1] into Subsurface's custom libdc [2]?
  
  Yes, in the Subsurface-testing branch (and this will be a force push
  because I prefer to rebase my changes on top of Jef's changes - this makes
  it much easier if Jef wants to look at what we are changing compared to
  hist master).
  
  I usually don't update the release related branches of libdivecomputer -
  or do you need the Subsurface-4.4 branch updated as well?
  
  
   It looks like a straightforward merge, but please let me know if there
   is anything I could do to help; I would be happy to.
  
  I need to apply Linus' changes as well. Let me take a look and see how it
  goes.
 
 As expected, no problems at all. Subsurface-testing branch is updated with
 the latest master from Jef and the last patches from Linus for the EON
 Steel.
 
 Let me know if you need anything else.

Thanks a lot!

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

Fix compiling against libgit2-0.22.1

[Gaetan Bisson]

Hi,

The attached patch fixes compile errors against libgit2-0.22.1.

It might not make sense at all but, for people like me who do not use
git storage but want to run a bleeding-edge subsurface, it does the job.
:)

Cheers.

-- 
Gaetan
From c8944f796712882b9ea7dced929c5af97e24889b Mon Sep 17 00:00:00 2001
From: Gaetan Bisson bis...@archlinux.org
Date: Sun, 14 Jun 2015 17:02:42 -1000
Subject: [PATCH] Fix compiling against libgit2-0.22.1

I have no idea whether the semantics is right, this patch was only
written so Subsurface compiles against the current stable release of
libgit2.

Signed-off-by: Gaetan Bisson bis...@archlinux.org
---
 git-access.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/git-access.c b/git-access.c
index 8433f70..22b407c 100644
--- a/git-access.c
+++ b/git-access.c
@@ -30,6 +30,13 @@
 #define git_remote_fetch(remote, refspecs, signature, reflog) git_remote_fetch(remote, signature, reflog)
   #endif
 #endif
+
+#if !LIBGIT2_VER_MAJOR  LIBGIT2_VER_MINOR == 22
+  #define git_remote_push(remote,refspecs,opts) git_remote_push(remote,refspecs,opts,NULL,NULL)
+  #define git_reference_set_target(out,ref,id,log_message) git_reference_set_target(out,ref,id,NULL,log_message)
+  #define git_reset(repo,target,reset_type,checkout_opts) git_reset(repo,target,reset_type,checkout_opts,NULL,NULL)
+#endif
+
 /*
  * api break introduced in libgit2 master after 0.22 - let's guess this is the v0.23 API
  */
-- 
2.4.3

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

Re: [PATCH] Save more planner settings into prefs

[Gaetan Bisson]

[2015-03-25 14:32:36 +0200] Lubomir I. Ivanov:
 it's usually best to put a sentence or two in the commit message about
 such side changes s well, because as you can see i though it's some
 sort of residue from a test case. :-)

Fair enough.

Here is the patch with a better commit message.

-- 
Gaetan
From 835e6efdbef6607a41c20f242fdf5b689fb97778 Mon Sep 17 00:00:00 2001
From: Gaetan Bisson bis...@archlinux.org
Date: Tue, 24 Mar 2015 11:57:22 -1000
Subject: [PATCH] Save more planner settings into prefs

This adds to the prefs struct the variables last_stop, verbatim_plan,
display_runtime, display_duration, and display_transitions from the
planner so their values are saved from one session to the next.

The widgets for some of those settings had default values in
plannerSettings.ui; remove them since the new code in
subsurfacestartup.c takes care of initializing them.

Signed-off-by: Gaetan Bisson bis...@archlinux.org
---
 pref.h   |  5 +
 qt-ui/diveplanner.cpp| 20 
 qt-ui/plannerSettings.ui |  6 --
 subsurfacestartup.c  |  5 +
 4 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/pref.h b/pref.h
index c33b554..fb01d28 100644
--- a/pref.h
+++ b/pref.h
@@ -73,6 +73,11 @@ struct preferences {
 	char *proxy_pass;
 	bool doo2breaks;
 	bool drop_stone_mode;
+	bool last_stop;
+	bool verbatim_plan;
+	bool display_runtime;
+	bool display_duration;
+	bool display_transitions;
 	int bottomsac;
 	int decosac;
 	int o2consumption; // ml per min
diff --git a/qt-ui/diveplanner.cpp b/qt-ui/diveplanner.cpp
index db00721..19c2661 100644
--- a/qt-ui/diveplanner.cpp
+++ b/qt-ui/diveplanner.cpp
@@ -388,6 +388,11 @@ PlannerSettingsWidget::PlannerSettingsWidget(QWidget *parent, Qt::WindowFlags f)
 	QSettings s;
 	QStringList rebreater_modes;
 	s.beginGroup(Planner);
+	prefs.last_stop = s.value(last_stop, prefs.last_stop).toBool();
+	prefs.verbatim_plan = s.value(verbatim_plan, prefs.verbatim_plan).toBool();
+	prefs.display_duration = s.value(display_duration, prefs.display_duration).toBool();
+	prefs.display_runtime = s.value(display_runtime, prefs.display_runtime).toBool();
+	prefs.display_transitions = s.value(display_transitions, prefs.display_transitions).toBool();
 	prefs.ascrate75 = s.value(ascrate75, prefs.ascrate75).toInt();
 	prefs.ascrate50 = s.value(ascrate50, prefs.ascrate50).toInt();
 	prefs.ascratestops = s.value(ascratestops, prefs.ascratestops).toInt();
@@ -404,6 +409,11 @@ PlannerSettingsWidget::PlannerSettingsWidget(QWidget *parent, Qt::WindowFlags f)
 	s.endGroup();
 
 	updateUnitsUI();
+	ui.lastStop-setChecked(prefs.last_stop);
+	ui.verbatim_plan-setChecked(prefs.verbatim_plan);
+	ui.display_duration-setChecked(prefs.display_duration);
+	ui.display_runtime-setChecked(prefs.display_runtime);
+	ui.display_transitions-setChecked(prefs.display_transitions);
 	ui.bottompo2-setValue(prefs.bottompo2 / 1000.0);
 	ui.decopo2-setValue(prefs.decopo2 / 1000.0);
 	ui.backgasBreaks-setChecked(prefs.doo2breaks);
@@ -459,6 +469,11 @@ PlannerSettingsWidget::~PlannerSettingsWidget()
 {
 	QSettings s;
 	s.beginGroup(Planner);
+	s.setValue(last_stop, prefs.last_stop);
+	s.setValue(verbatim_plan, prefs.verbatim_plan);
+	s.setValue(display_duration, prefs.display_duration);
+	s.setValue(display_runtime, prefs.display_runtime);
+	s.setValue(display_transitions, prefs.display_transitions);
 	s.setValue(ascrate75, prefs.ascrate75);
 	s.setValue(ascrate50, prefs.ascrate50);
 	s.setValue(ascratestops, prefs.ascratestops);
@@ -813,30 +828,35 @@ int DivePlannerPointsModel::getSurfacePressure()
 void DivePlannerPointsModel::setLastStop6m(bool value)
 {
 	set_last_stop(value);
+	prefs.last_stop = value;
 	emit dataChanged(createIndex(0, 0), createIndex(rowCount() - 1, COLUMNS - 1));
 }
 
 void DivePlannerPointsModel::setVerbatim(bool value)
 {
 	set_verbatim(value);
+	prefs.verbatim_plan = value;
 	emit dataChanged(createIndex(0, 0), createIndex(rowCount() - 1, COLUMNS - 1));
 }
 
 void DivePlannerPointsModel::setDisplayRuntime(bool value)
 {
 	set_display_runtime(value);
+	prefs.display_runtime = value;
 	emit dataChanged(createIndex(0, 0), createIndex(rowCount() - 1, COLUMNS - 1));
 }
 
 void DivePlannerPointsModel::setDisplayDuration(bool value)
 {
 	set_display_duration(value);
+	prefs.display_duration = value;
 	emit dataChanged(createIndex(0, 0), createIndex(rowCount() - 1, COLUMNS - 1));
 }
 
 void DivePlannerPointsModel::setDisplayTransitions(bool value)
 {
 	set_display_transitions(value);
+	prefs.display_transitions = value;
 	emit dataChanged(createIndex(0, 0), createIndex(rowCount() - 1, COLUMNS - 1));
 }
 
diff --git a/qt-ui/plannerSettings.ui b/qt-ui/plannerSettings.ui
index 440fb53..0951e32 100644
--- a/qt-ui/plannerSettings.ui
+++ b/qt-ui/plannerSettings.ui
@@ -501,9 +501,6 @@
 property name=text
  stringDisplay runtime/string
 /property
-property name=checked
- booltrue/bool
-/property

Re: [PATCH] Save more planner settings into prefs

[Gaetan Bisson]

Hi Lubomir,

[2015-03-25 00:27:20 +0200] Lubomir I. Ivanov:
 any reason to also update the plannerSettings.ui file; perhaps residue
 from tests while you were developing the patch?
 the commit notes don't explain this particular change.

The new code in subsurfacestartup.c takes care of initializing those
settings, so there is no need to set default values for the widgets in
plannerSettings.ui .

Cheers.

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

Re: Begin of Facebook Integration

[Gaetan Bisson]

Thanks Tomaz for the hard work; just a comment:

[2014-12-24 13:28:58 -0200] Tomaz Canabrava:
 +#include QJsonDocument

This requires Qt5. Should Qt4 builds still be supported?

Cheers.

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

Re: Begin of Facebook Integration

[Gaetan Bisson]

Thanks Tomaz for the hard work; just a comment:

[2014-12-24 13:28:58 -0200] Tomaz Canabrava:
 +#include QJsonDocument

This requires Qt5. Should Qt4 builds still be supported?

Cheers.

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

Re: Begin of Facebook Integration

[Gaetan Bisson]

[2014-12-24 18:10:03 -0800] Dirk Hohndel:
 I'm considering dropping Qt4 support for 4.4

Ah, OK, I'll compile marble for Qt5 then. :)

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

Re: [PATCH] main.cpp: fix broken build for libgit2 0.21

[Gaetan Bisson]

[2014-12-07 20:32:14 +0200] Lubomir I. Ivanov:
 so if 'git_libgit2_init' isn't there and this is the case for version.h:
 #define LIBGIT2_VER_MAJOR 0
 #define LIBGIT2_VER_MINOR 21
 
 there is no solution...it could be that the distro used another branch
 to build the library.
 
 from one of my earlier messages:
  799e22ea (API broken) is after 4fb32a44 (version.h bumped to 0.21).
 
 799e22ea made the git_libgit2_init() change.

Well, there is no occurrence of libgit2_init in the 0.21.1 tarball:

https://github.com/libgit2/libgit2/archive/v0.21.1.tar.gz

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

Re: Two more rebreather patches

[Gaetan Bisson]

[2014-10-27 15:52:59 -0700] Dirk Hohndel:
 On Mon, Oct 27, 2014 at 08:14:44PM +0100, Anton Lundin wrote:
  On 27 October, 2014 - Gaetan Bisson wrote:
  
   [2014-10-24 16:48:34 +0200] Robert Helling:
what happened to Gaetan’s attempts at coming up with a UI 
implementation?
   
   I wanted to do something basic and Anton convinced me that would be a
   shame and something much better should be done instead. Since GUIs are
   the complete opposite to my area of expertise, I just stopped thinking
   about this.
  
  Something is always better then nothing. Give it a try!
 
 +1  -- if we have something then we can talk about what should be
 differently and make that happen. If we have nothing it's really hard for
 the UI experts to start working.

Thanks for the motivation; I'll give this a go when I find the time,
which probably won't be before a couple of weeks, but I'll get there
eventually.

Cheers.

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

Re: OSTC3 import failure

[Gaetan Bisson]

[2014-10-09 21:38:59 -0400] Dirk Hohndel:
 Can you post the output of subsurface --version ?

It's a fairly recent git build of libdivecomputer:

Subsurface v4.2-201-g84fdbefb58c7, built with libdivecomputer
v0.5.0-devel (5f765f91430f16932d96b3777404420aa2dd4c7c)

  INFO: Read: size=538, 
  data=001C3A00090035370009001620001F0D0100F043300019190009001719000909000D0D0100FB0A000900070A0009000A0B001F0D0100F045390B00090009090009000B0B000D0D0100FA0B0009000A0A0009000A0A001F0D0100F0443B0A0009000909000900090A000D0D0100FC0B000900070B0009000908001F0D0100F04339090009000A090009000B09000D0D0100F9090009000B0C0009000B09001F0D0100F0423000FDFD
  INFO: Read: size=1, data=4D
  ERROR: Buffer overflow detected! [in hw_ostc_parser.c:598 
  (hw_ostc_parser_samples_foreach)]
 
 Now I may be overly suspicious, but I think this pretty much points us at
 the culprit...
 
 This is the code that triggers this (at least in my version of
 libdivecomputer which is pretty close to git master plus a few of my own
 patches that haven't made it into libdivecomputer, yet, but those are
 unrelated to the OSTC)
 
// Extended sample info.
 for (unsigned int i = 0; i  nconfig; ++i) {
 if (info[i].divisor  (nsamples % info[i].divisor) 
 == 0) {
 if (length  info[i].size) {
 ERROR (abstract-context, Buffer 
 overflow detected!);
 return DC_STATUS_DATAFORMAT;
 }
 
 So it looks like the last read (which returned 1 byte) was expected to
 deliver a lot more data. I haven't gone through the data stream to analyze
 what exactly the OSTC3 was sending that confused libdivecomputer, but it's
 pretty clear this is where the problem is.

Thanks. The dive looks fine in the internal OSTC3 logbook, so it seems
unlikely that the dive computer memory is corrupted. I'm running a
stable but fairly recent firmware (version 1.50) so that could also be
the issue although I have been running it for a few weeks already with
no dive import problem until today.

Cheers.

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