iOS build 4.9.3.1486

2020-04-21 Thread Hartley Horwitz via subsurface 
I've done some basic checks on the latest iOS build.
* loading a local file
* syncing with cloud
* edits, undo, redo (1 level only)
* save back to cloud
* restart app, reload from cloud to confirm changes

All looks good.  I'm probably not the best tester for this release because
I wasn't experiencing issues with the cloud and I've been using the app a
lot in the last week.

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

Re: new CI builds

2020-04-21 Thread Chirana Gheorghita Eugeniu Theodor via subsurface 
1495 seems to solve the crash issue on fedora 31. I was able to add a dive,
edit it, save it  delete it.
More testing to follow. Any specific tests in your mind ?

On Tue, Apr 21, 2020, 19:28 Dirk Hohndel  wrote:

> On Tue, 2020-04-21 at 07:29 -0700, Dirk Hohndel via subsurface wrote:
> > On Tue, 2020-04-21 at 12:12 +0300, Chirana Gheorghita Eugeniu Theodor
> > wrote:
> > > push to obs pls.
> > >
> >
> > He can't. OBS builds are semi-automatically triggered by merges into
> > master - for reasons I haven't figured out so far, I often have to
> > manually nudge them to get started.
> >
>
> -1495 (which includes these changes) is available for SUSE/Fedora as
> well as Ubuntu Bionic. Launchpad is having network issues. It took
> about 100x longer than normal to upload sources. Eoan is almost done
> building, Focal just started.
>
> I am planning to also create a more reliable way to have Windows
> installers show up as we have seen a number of instances where GitHub
> actions "lost" the binaries.
>
> Unrelated to the upcoming desktop release, we now also have signed
> Android APKs available for every push on downloads/test on our website
> (that's where the Windows installers will be hosted as well).
>
> /D
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: new CI builds

2020-04-21 Thread Dirk Hohndel via subsurface 
On Tue, 2020-04-21 at 07:29 -0700, Dirk Hohndel via subsurface wrote:
> On Tue, 2020-04-21 at 12:12 +0300, Chirana Gheorghita Eugeniu Theodor
> wrote:
> > push to obs pls.
> > 
> 
> He can't. OBS builds are semi-automatically triggered by merges into
> master - for reasons I haven't figured out so far, I often have to
> manually nudge them to get started.
> 

-1495 (which includes these changes) is available for SUSE/Fedora as
well as Ubuntu Bionic. Launchpad is having network issues. It took
about 100x longer than normal to upload sources. Eoan is almost done
building, Focal just started.

I am planning to also create a more reliable way to have Windows
installers show up as we have seen a number of instances where GitHub
actions "lost" the binaries.

Unrelated to the upcoming desktop release, we now also have signed
Android APKs available for every push on downloads/test on our website
(that's where the Windows installers will be hosted as well).

/D

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

Re: new CI builds

2020-04-21 Thread Dirk Hohndel via subsurface 
On Tue, 2020-04-21 at 09:25 +0200, Dietrich Meyer via subsurface wrote:
> > For Linux Fedora add new dive from Log > New dive still crashes the
> > app:
> > > Ok.
> > > First test failed on linux.
> > > I click Log > Add dive and app crashes. Where is the log of the
> > > app in
> > > linux? I can dig it out but I am too lazy now.�
> 
> Cannot reproduce this on Opensuse 15.1
> Updated to 4.9.3.-1492 this morning (using the version from OBS),
> also added 
> new dive there. No problem.

That is excellent input. Thank you so much for testing this!
So it likely is indeed a result of the different compiler flags used by
the distro.

/D

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

Re: new CI builds

2020-04-21 Thread Dirk Hohndel via subsurface 
On Tue, 2020-04-21 at 09:20 +0200, Berthold Stoeger wrote:
> Ok, this one is weird.
> 
> 
> That appears to be g++, right? To me this looks like it trips on an
> assertion 
> of a "vector[n]" access. The one thing I found in the offending
> function was a 
> construct of the type
>   "[0]"
> to pass an array down to C, which *technically* is indeed undefined
> behavior 
> if "mean" is empty. However, the whole point of operator[] is that it
> is 
> unchecked and as long as the callee doesn't access the array, this
> should work 
> just fine. After all it is only taking an address.

Ah the beauty of corner cases...

> Therefore, I replaced above construct by "mean.data()" and put the
> call in an 
> if for good measure:
>   https://github.com/Subsurface-divelog/subsurface/pull/2778
> Please test this.

As I mentioned in my other response... there are no OBS builds for PRs.

> If my suspicion is correct, I consider that very unfriendly behavior
> of the 
> compiler / library. @Dirk: does that version compile with other than
> the 
> default settings?

You can see the settings used in packaging/OBS

   cmake -DCMAKE_BUILD_TYPE=Release \
-DLRELEASE=lrelease-qt5 \
-DCMAKE_INSTALL_PREFIX=%{buildroot}/usr \

-DLIBDIVECOMPUTER_INCLUDE_DIR=$RPM_BUILD_DIR/install-root/include \
-DLIBGIT2_INCLUDE_DIR=$RPM_BUILD_DIR/install-root/include \

-DLIBDIVECOMPUTER_LIBRARIES=$RPM_BUILD_DIR/install-root/lib/libdivecomputer.a \
-DCMAKE_C_FLAGS:STRING="%optflags" \
-DCMAKE_CXX_FLAGS:STRING="%optflags" \
-DNO_PRINTING=OFF \
.. ; \
make VERBOSE=1 %{?_smp_mflags} subsurface)

My theory would be that the difference we are seeing here is that
different distributions use different flags as '%optflags' for
compilations and we inherit those. And of course, we build with clang
on Mac/iOS/Android and gcc for Windows and (I believe) all of the Linux
builds.

/D

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

Re: new CI builds

2020-04-21 Thread Dirk Hohndel via subsurface 
On Tue, 2020-04-21 at 12:12 +0300, Chirana Gheorghita Eugeniu Theodor
wrote:
> push to obs pls.
> 

He can't. OBS builds are semi-automatically triggered by merges into
master - for reasons I haven't figured out so far, I often have to
manually nudge them to get started.

Berthold has created a Pull Request for others to review - those do NOT
trigger OBS or Launchpad builds - only GitHub Action builds

/D

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

Re: new CI builds

2020-04-21 Thread Dirk Hohndel via subsurface 
On Tue, 2020-04-21 at 14:13 +0200, Willem Ferguson wrote:
> Using 4.9.3-1480 on Ubuntu 18.04
> 
> I downloaded this version from the Ubuntu ppa provided by Dirk.
> 
> (one question in total ignorance. Is this package a snap?)

No, the PPA gives you "native" binaries for Ubuntu.

> I downloaded using both Bluetooth and iRDA, no problems. Edited
> these 
> dives. No problem.
> 
> Tested all the options I could on the dive list context menu. No
> problem.
> 
> Tested all the possible preference values. No problem.
> 
> Created a dive manually with Log->Add dive. No problem. Edited
> profile 
> by hand and manipulated the info in the various text boxes. Saved
> them. 
> No problem.

Excellent. Thanks for all the testing - it's good to know that at least
on some platform things are going to plan.

/D

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

Re: new CI builds

2020-04-21 Thread Willem Ferguson via subsurface 

Using 4.9.3-1480 on Ubuntu 18.04

I downloaded this version from the Ubuntu ppa provided by Dirk.

(one question in total ignorance. Is this package a snap?)

I downloaded using both Bluetooth and iRDA, no problems. Edited these 
dives. No problem.


Tested all the options I could on the dive list context menu. No problem.

Tested all the possible preference values. No problem.

Created a dive manually with Log->Add dive. No problem. Edited profile 
by hand and manipulated the info in the various text boxes. Saved them. 
No problem.


Kind regards,

willem




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

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

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

Re: new CI builds

2020-04-21 Thread Chirana Gheorghita Eugeniu Theodor via subsurface 
push to obs pls.

On Tue, Apr 21, 2020, 10:20 Berthold Stoeger 
wrote:

> Ok, this one is weird.
>
> On Dienstag, 21. April 2020 08:44:09 CEST Chirana Gheorghita Eugeniu
> Theodor
> wrote:
>
> > /usr/include/c++/9/bits/stl_vector.h:1042: std::vector<_Tp,
> > _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp,
> > _Alloc>::size_type) [with _Tp = int; _Alloc = std::allocator;
> > std::vector<_Tp, _Alloc>::reference = int&; std::vector<_Tp,
> > _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n
> <
> > this->size(), true)' failed.
>
> That appears to be g++, right? To me this looks like it trips on an
> assertion
> of a "vector[n]" access. The one thing I found in the offending function
> was a
> construct of the type
>   "[0]"
> to pass an array down to C, which *technically* is indeed undefined
> behavior
> if "mean" is empty. However, the whole point of operator[] is that it is
> unchecked and as long as the callee doesn't access the array, this should
> work
> just fine. After all it is only taking an address.
>
> Therefore, I replaced above construct by "mean.data()" and put the call in
> an
> if for good measure:
>   https://github.com/Subsurface-divelog/subsurface/pull/2778
> Please test this.
>
> If my suspicion is correct, I consider that very unfriendly behavior of
> the
> compiler / library. @Dirk: does that version compile with other than the
> default settings?
>
> Berthold
>
>
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: new CI builds

2020-04-21 Thread Dietrich Meyer via subsurface 

> For Linux Fedora add new dive from Log > New dive still crashes the app:
> > Ok.
> > First test failed on linux.
> > I click Log > Add dive and app crashes. Where is the log of the app in
> > linux? I can dig it out but I am too lazy now.


Cannot reproduce this on Opensuse 15.1
Updated to 4.9.3.-1492 this morning (using the version from OBS), also added 
new dive there. No problem.


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

Re: new CI builds

2020-04-21 Thread Berthold Stoeger via subsurface 
Ok, this one is weird.

On Dienstag, 21. April 2020 08:44:09 CEST Chirana Gheorghita Eugeniu Theodor 
wrote:

> /usr/include/c++/9/bits/stl_vector.h:1042: std::vector<_Tp,
> _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp,
> _Alloc>::size_type) [with _Tp = int; _Alloc = std::allocator;
> std::vector<_Tp, _Alloc>::reference = int&; std::vector<_Tp,
> _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n <
> this->size(), true)' failed.

That appears to be g++, right? To me this looks like it trips on an assertion 
of a "vector[n]" access. The one thing I found in the offending function was a 
construct of the type
  "[0]"
to pass an array down to C, which *technically* is indeed undefined behavior 
if "mean" is empty. However, the whole point of operator[] is that it is 
unchecked and as long as the callee doesn't access the array, this should work 
just fine. After all it is only taking an address.

Therefore, I replaced above construct by "mean.data()" and put the call in an 
if for good measure:
  https://github.com/Subsurface-divelog/subsurface/pull/2778
Please test this.

If my suspicion is correct, I consider that very unfriendly behavior of the 
compiler / library. @Dirk: does that version compile with other than the 
default settings?

Berthold



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

Re: new CI builds

2020-04-21 Thread Chirana Gheorghita Eugeniu Theodor via subsurface 
Also for the Ci-release to get the win version I do not see any builds.
just source code

On Tue, Apr 21, 2020, 09:44 Chirana Gheorghita Eugeniu Theodor <
off...@adaptcom.ro> wrote:

> For Linux Fedora add new dive from Log > New dive still crashes the app:
>
> [test@localhost ~]$ subsurface.debug
> QSocketNotifier: Can only be used with threads started with QThread
> QSocketNotifier: Can only be used with threads started with QThread
> Non-toplevel surfaces can't request window states
> Wayland does not support QWindow::requestActivate()
> Non-toplevel surfaces can't request window states
> Wayland does not support QWindow::requestActivate()
> Wayland does not support QWindow::requestActivate()
> Non-toplevel surfaces can't request window states
> Wayland does not support QWindow::requestActivate()
> Wayland does not support QWindow::requestActivate()
> Non-toplevel surfaces can't request window states
> Wayland does not support QWindow::requestActivate()
> Wayland does not support QWindow::requestActivate()
> Non-toplevel surfaces can't request window states
> Wayland does not support QWindow::requestActivate()
> Wayland does not support QWindow::requestActivate()
> Non-toplevel surfaces can't request window states
> Wayland does not support QWindow::requestActivate()
> /usr/include/c++/9/bits/stl_vector.h:1042: std::vector<_Tp,
> _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp,
> _Alloc>::size_type) [with _Tp = int; _Alloc = std::allocator;
> std::vector<_Tp, _Alloc>::reference = int&; std::vector<_Tp,
> _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n <
> this->size(), true)' failed.
> /usr/bin/subsurface.debug: line 109:  3494 Aborted (core
> dumped) "${prefix}/bin/${bin_name}" $SAVED_ARGS
>PID: 3404 (subsurface)
>UID: 1000 (test)
>GID: 1000 (test)
> Signal: 6 (ABRT)
>  Timestamp: Tue 2020-04-21 09:42:06 EEST (33s ago)
>   Command Line: subsurface
> Executable: /usr/bin/subsurface
>  Control Group: /user.slice/user-1000.slice/user@1000.service
> /gnome-launched-subsurface.desktop-3404.scope
>   Unit: user@1000.service
>  User Unit: gnome-launched-subsurface.desktop-3404.scope
>  Slice: user-1000.slice
>  Owner UID: 1000 (test)
>Boot ID: 6d03e3e91f554f428d203063cdee472f
> Machine ID: f7766dd1407941258ce0ebadf751659e
>   Hostname: localhost.localdomain
>Storage:
> /var/lib/systemd/coredump/core.subsurface.1000.6d03e3e91f554f428d203063cdee472f.3404.1587451326.lz4
>Message: Process 3404 (subsurface) of user 1000 dumped core.
>
> Stack trace of thread 3404:
> #0  0x7f8639a98625 raise (libc.so.6)
> #1  0x7f8639a818d9 abort (libc.so.6)
> #2  0x00623458
> _ZSt20__replacement_assertPKciS0_S0_ (subsurface)
> #3  0x0062086f
> _ZN18TabDiveInformation13updateProfileEv (subsurface)
> #4  0x00621f06
> _ZN18TabDiveInformation10updateDataEv (subsurface)
> #5  0x0054de51 _ZN7MainTab14updateDiveInfoEv
> (subsurface)
> #6  0x00524cd3 _ZN10MainWindow16selectionChangedEv
> (subsurface)
> #7  0x7f863a20ef40
> _ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
> #8  0x005b6779
> _ZN12DiveListView19selectionChangeDoneEv (subsurface)
> #9  0x005b695d
> _ZN12DiveListView20diveSelectionChangedERK7QVectorI11QModelIndexE
> (subsurface)
> #10 0x7f863a20ef40
> _ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
> #11 0x006696c6
> _ZN20MultiFilterSortModel16selectionChangedERK7QVectorI11QModelIndexE
> (subsurface)
> #12 0x0069daf4
> _ZN20MultiFilterSortModel20selectionChangedSlotERK7QVectorI11QModelIndexE
> (subsurface)
> #13 0x7f863a20ef40
> _ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
> #14 0x00669616
> _ZN17DiveTripModelBase16selectionChangedERK7QVectorI11QModelIndexE
> (subsurface)
> #15 0x00686654
> _ZN17DiveTripModelTree13divesSelectedERK7QVectorIP4diveE (subsurface)
> #16 0x7f863a20ef40
> _ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
> #17 0x006c4ce9
> _ZN16DiveListNotifier13divesSelectedERK7QVectorIP4diveE (subsurface)
> #18 0x00767294
> _Z12setSelectionRKSt6vectorIP4diveSaIS1_EES1_ (subsurface)
> #19 0x006aa0eb _ZN7Command7AddDive6redoitEv
> (subsurface)
> #20 0x006a65da _ZN7Command12DiveListBase4redoEv
> (subsurface)
> #21 0x7f863bb65d2a
> _ZN10QUndoStack4pushEP12QUndoCommand (libQt5Widgets.so.5)
> #22 0x006a2baf _ZN7Command7executeEPNS_4BaseE
> (subsurface)
>

Re: new CI builds

2020-04-21 Thread Chirana Gheorghita Eugeniu Theodor via subsurface 
For Linux Fedora add new dive from Log > New dive still crashes the app:

[test@localhost ~]$ subsurface.debug
QSocketNotifier: Can only be used with threads started with QThread
QSocketNotifier: Can only be used with threads started with QThread
Non-toplevel surfaces can't request window states
Wayland does not support QWindow::requestActivate()
Non-toplevel surfaces can't request window states
Wayland does not support QWindow::requestActivate()
Wayland does not support QWindow::requestActivate()
Non-toplevel surfaces can't request window states
Wayland does not support QWindow::requestActivate()
Wayland does not support QWindow::requestActivate()
Non-toplevel surfaces can't request window states
Wayland does not support QWindow::requestActivate()
Wayland does not support QWindow::requestActivate()
Non-toplevel surfaces can't request window states
Wayland does not support QWindow::requestActivate()
Wayland does not support QWindow::requestActivate()
Non-toplevel surfaces can't request window states
Wayland does not support QWindow::requestActivate()
/usr/include/c++/9/bits/stl_vector.h:1042: std::vector<_Tp,
_Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp,
_Alloc>::size_type) [with _Tp = int; _Alloc = std::allocator;
std::vector<_Tp, _Alloc>::reference = int&; std::vector<_Tp,
_Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n <
this->size(), true)' failed.
/usr/bin/subsurface.debug: line 109:  3494 Aborted (core
dumped) "${prefix}/bin/${bin_name}" $SAVED_ARGS
   PID: 3404 (subsurface)
   UID: 1000 (test)
   GID: 1000 (test)
Signal: 6 (ABRT)
 Timestamp: Tue 2020-04-21 09:42:06 EEST (33s ago)
  Command Line: subsurface
Executable: /usr/bin/subsurface
 Control Group: /user.slice/user-1000.slice/user@1000.service
/gnome-launched-subsurface.desktop-3404.scope
  Unit: user@1000.service
 User Unit: gnome-launched-subsurface.desktop-3404.scope
 Slice: user-1000.slice
 Owner UID: 1000 (test)
   Boot ID: 6d03e3e91f554f428d203063cdee472f
Machine ID: f7766dd1407941258ce0ebadf751659e
  Hostname: localhost.localdomain
   Storage:
/var/lib/systemd/coredump/core.subsurface.1000.6d03e3e91f554f428d203063cdee472f.3404.1587451326.lz4
   Message: Process 3404 (subsurface) of user 1000 dumped core.

Stack trace of thread 3404:
#0  0x7f8639a98625 raise (libc.so.6)
#1  0x7f8639a818d9 abort (libc.so.6)
#2  0x00623458 _ZSt20__replacement_assertPKciS0_S0_
(subsurface)
#3  0x0062086f
_ZN18TabDiveInformation13updateProfileEv (subsurface)
#4  0x00621f06
_ZN18TabDiveInformation10updateDataEv (subsurface)
#5  0x0054de51 _ZN7MainTab14updateDiveInfoEv
(subsurface)
#6  0x00524cd3 _ZN10MainWindow16selectionChangedEv
(subsurface)
#7  0x7f863a20ef40
_ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
#8  0x005b6779
_ZN12DiveListView19selectionChangeDoneEv (subsurface)
#9  0x005b695d
_ZN12DiveListView20diveSelectionChangedERK7QVectorI11QModelIndexE
(subsurface)
#10 0x7f863a20ef40
_ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
#11 0x006696c6
_ZN20MultiFilterSortModel16selectionChangedERK7QVectorI11QModelIndexE
(subsurface)
#12 0x0069daf4
_ZN20MultiFilterSortModel20selectionChangedSlotERK7QVectorI11QModelIndexE
(subsurface)
#13 0x7f863a20ef40
_ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
#14 0x00669616
_ZN17DiveTripModelBase16selectionChangedERK7QVectorI11QModelIndexE
(subsurface)
#15 0x00686654
_ZN17DiveTripModelTree13divesSelectedERK7QVectorIP4diveE (subsurface)
#16 0x7f863a20ef40
_ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5)
#17 0x006c4ce9
_ZN16DiveListNotifier13divesSelectedERK7QVectorIP4diveE (subsurface)
#18 0x00767294
_Z12setSelectionRKSt6vectorIP4diveSaIS1_EES1_ (subsurface)
#19 0x006aa0eb _ZN7Command7AddDive6redoitEv
(subsurface)
#20 0x006a65da _ZN7Command12DiveListBase4redoEv
(subsurface)
#21 0x7f863bb65d2a _ZN10QUndoStack4pushEP12QUndoCommand
(libQt5Widgets.so.5)
#22 0x006a2baf _ZN7Command7executeEPNS_4BaseE
(subsurface)
#23 0x00525439
_ZN10MainWindow26on_actionAddDive_triggeredEv (subsurface)
#24 0x0057404e
_ZN10MainWindow18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv
(subsurface)
#25 0x00578423
_ZN10MainWindow11qt_metacallEN11QMetaObject4CallEiPPv (subsurface)
#26 0x7f863a20eebc