updated current release

2024-08-15 Thread Dirk Hohndel via subsurface
Hi there,

The Linux distro builds have been kicked off.
AppImage, Android, macOS, and Windows are in place.
The iOS build is as usual a bit behind - it's still waiting to be approved by 
Apple for beta testing; after a couple of days of that I'll push that one out 
as the next release as well.

I updated the web site and verified that the update service also reports the 
correct version as 'current'.

Please let me know if you spot something that seems 'off'.

Amazing work by Michael Keller to keep it all going and doing the majority of 
the work these days.

/D
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


Re: Unable to access to cloud data

2024-07-20 Thread Dirk Hohndel via subsurface


> On Jul 20, 2024, at 05:59, John  wrote:
> 
> I’ve just got a new android tablet and was trying to load subsurface.
> 
> It loaded yesterday and brought in my dives, but today kept crashing.

Which version? How did you install it?

> I tried accessing my cloud via my iPad and iPhone and can’t see anything data.
> 
> Could someone check my cloud data please or remind me how to access the cloud 
> data via a browser?

https://cloud.subsurface-divelog.org  
and log in with your cloud credentials.

/D___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


Re: Sync with cloud fails on iPhone app

2024-06-19 Thread Dirk Hohndel via subsurface
Hey Miika

> On Jun 19, 2024, at 00:04, Miika Turkia  wrote:
> 
> There seems to be something wrong with the cloud sync on iPhone app. I have 
> downloaded some new dives to the mobile app, but they do not appear on the 
> cloud when checking from cloud.subsurface-divelog.org 
> .
> 
> When forcing manual sync, app claims that sync was completed, but nothing is 
> visible on the web page / when trying git pull manually.
> 
> Trying to check logs on the app do not reveal me anything useful. It does say 
> that connection to cloud server was successful, but does not show data to be 
> pushed there.
> 
> iOS 17.5.1
> Subsurface 6.0.5209

Can you send a support request from within the app after you did a manual sync?
I'd love to see that full log to understand why that would not be working.
It seems to work here and there hasn't been any recent change that I can think 
of that should cause this - but then again, this is iOS, so anything is 
possible...

Seeing the full log might help me look at the server logs and the iOS logs and 
figure out what happened...

/D

___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


Re: recent build failures...

2024-04-24 Thread Dirk Hohndel via subsurface
Rewriting this would be a huge mistake. 

There are like four working units left, three of the owners use Subsurface, two 
of them have carefully hacked the existing code to work for them...

Please don't touch this. 

It's reverse engineered from a reverse engineered Java app, and then reworked a 
couple of times. 

I used to have three of these monsters, they are all dead now

/D

On April 24, 2024 9:01:31 PM PDT, Berthold Stoeger  
wrote:
>On Donnerstag, 25. April 2024 02:16:12 CEST Dirk Hohndel via subsurface wrote:
>> > On Apr 24, 2024, at 11:44, Linus Torvalds 
>> > wrote:
>> > 
>> > On Wed, 24 Apr 2024 at 11:13, Dirk Hohndel via subsurface
>> > 
>> >  wrote:
>> >> Those with better skills in interpreting error messages... what am I
>> >> missing?> 
>> > I think the line numbers are wrong, probably because of inlining etc.
>> 
>> > The real issue is _probably_ on line 525:
>> I don't think you are correct... I got fooled by the weird error output.
>> The real error is in line 290:
>> [...]
>
>Incidentally, I just started reworking uemis-downloader.cpp and uemis.cpp.
>
>I think the correct fix is to simply not use snprintf() et al., but instead 
>use std::string 
>instead. This makes things so much clearer for everybody (including the 
>compiler). printf-
>style formatting is fundamentally broken.
>
>Concerning uemis-downloader.cpp, I noticed an odd thing: there is a "newmax" 
>variable 
>that contains an integer formatted as a string(!).
>
>The memory for that string is allocated in uemis_get_divenr(). The owner of 
>the memory 
>seems to be do_uemis_import() (who never frees it, by the way). However:
>
>1) do_uemis_import() passes "newmax" as "char *" to get_matching_dive() (i.e. 
>with "value 
>semantics").
>
>2) get_matching_dive() then passes a pointer to the local "newmax" (char **) 
>to 
>process_raw_buffer() (i.e. with "reference semantics"). 
>
>3) process_raw_buffer() may reallocate the string and overwrite "newmax".
>
>The problem: only the local version of newmax in get_matching_dive() is 
>overwritten. 
>do_uemis_import() still has a pointer to the now free()d memory.
>
>Am I missing something? Can you shed some light on this?
>
>I would suggest to replace "newmax" by an integer variable. But should that be 
>passed 
>using value or reference semantics from do_uemis_import() to 
>get_matching_dive()?
>
>Berthold
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


Re: recent build failures...

2024-04-24 Thread Dirk Hohndel via subsurface


> On Apr 24, 2024, at 11:44, Linus Torvalds  
> wrote:
> 
> On Wed, 24 Apr 2024 at 11:13, Dirk Hohndel via subsurface
>  wrote:
>> 
>> Those with better skills in interpreting error messages... what am I missing?
> 
> I think the line numbers are wrong, probably because of inlining etc.
> 
> The real issue is _probably_ on line 525:

I don't think you are correct... I got fooled by the weird error output.
The real error is in line 290:

/<>/core/uemis-downloader.cpp:290:32: error: ‘%s’ directive output 
between 0 and 12 bytes may cause result to exceed ‘INT_MAX’ 
[-Werror=format-truncation=]
 290 | snprintf(buf, len, "%s/%s", path, name);
 |^~

Reading through the logic behind the warning it is... questionable. And turning 
the 
warning into an error of course makes this all even more annoying.
https://stackoverflow.com/questions/51534284/how-to-circumvent-format-truncation-warning-in-gcc

I think this will make the compiler shut up and the build not fail. It's... 
demented, 
MHO, but what can I say...

diff --git a/core/uemis-downloader.cpp b/core/uemis-downloader.cpp
index 37bdfce23..ff64f39ba 100644
--- a/core/uemis-downloader.cpp
+++ b/core/uemis-downloader.cpp
@@ -285,10 +285,12 @@ static char *build_filename(const char *path, const char 
*name)
int len = strlen(path) + strlen(name) + 2;
char *buf = (char *)malloc(len);
 #if WIN32
-   snprintf(buf, len, "%s\\%s", path, name);
+   l = snprintf(buf, len, "%s\\%s", path, name);
 #else
-   snprintf(buf, len, "%s/%s", path, name);
+   l = snprintf(buf, len, "%s/%s", path, name);
 #endif
+   if(l < 0 or l > len)
+   printf("this compiler is broken -- snprintf returned %d\n", l);
return buf;
 }
 

Now, separately, the below code also could create stupid warnings. So I elected 
to
create even more silly code to fix that as well.

> 
>snprintf(fl, 13, "ANS%d.TXT", filenumber);
> 
> where the compiler things that the 13 byte buffer is not enough for
> some integers (ie "%d" could be "-2147483648", which is 11 characters
> just there). Thus the "0..12" thing.
> 
> And yes, we do that clamping to 0.., but I suspect the compiler
> can't quite follow it, and doesn't quite figure out that the max is
> 3+4+4+1.
> 
> And it probably all depends on compiler version and just random
> phase-of-the-moon things.
> 
> But my guess is that you should change the magic "13" to be something
> bigger, preferably something that is safe for any integer so that the
> compiler doesn't have to understand the clamping logic.
> 
> Alternatively, make it easier for the compiler to understand the
> clamping: maybe make 'filenumber' be unsigned (and make the "%d" be
> "%u), and then just do
> 
>if (filenumber > UEMIS_MAX_FILES)
>filenumber = 0;
> 
> which is a *lot* easier for a compiler to understand than the
> currently "conditional signed modulus" operation it does.

@@ -517,14 +519,10 @@ static void uemis_increased_timeout(int *timeout)
 
 static char *build_ans_path(const char *path, int filenumber)
 {
-   char *intermediate, *ans_path, fl[13];
+   char *intermediate, *ans_path, fl[15];
 
-   /* Clamp filenumber into the 0.. range. This is never necessary,
-* as filenumber can never go above UEMIS_MAX_FILES, but gcc doesn't
-* recognize that and produces very noisy warnings. */
-   filenumber = filenumber < 0 ? 0 : filenumber % 1;
-
-   snprintf(fl, 13, "ANS%d.TXT", filenumber);
+   uint16_t fn =  (filenumber < 0 || filenumber > UEMIS_MAX_FILES) ? 0 : 
filenumber;
+   snprintf(fl, 13, "ANS%u.TXT", fn);
intermediate = build_filename(path, "ANS");
ans_path = build_filename(intermediate, fl);
free(intermediate);

This feels equally demented, but at least stops the warning 🤦🏻‍♂️

/D___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


recent build failures...

2024-04-24 Thread Dirk Hohndel via subsurface

I read this three times and I'm still not quite sure what this is telling me:

/<>/core/uemis-downloader.cpp: In function ‘build_ans_path(char 
const*, int)’:
/<>/core/uemis-downloader.cpp:290:32: error: ‘%s’ directive output 
between 0 and 12 bytes may cause result to exceed ‘INT_MAX’ 
[-Werror=format-truncation=]
  290 | snprintf(buf, len, "%s/%s", path, name);
  |^~
..
  529 | ans_path = build_filename(intermediate, fl);
  | ~~

This is causing some of our automated builds to fail.
Those with better skills in interpreting error messages... what am I missing?

/D
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


Italian version of Subsurface-mobile on iOS shows Korean UI

2024-03-15 Thread Dirk Hohndel via subsurface


I spent a ridiculous amount of time trying to find out which memory corruption 
or which recent change to our handling of translations would have caused this 
weird bug.
And as usual, it turned out to be something insanely stupid and insanely 
obvious. A silly cut and paste error. And I should have looked there much 
earlier, because it was so odd that it was JUST the Italian translation and 
ONLY on iOS.

Oh well. I just pushed a fix into master (ignoring the PR process as that 
doesn't create working iOS builds that we could test, anyway), and I'm 
uploading a new binary for iOS as we speak.
Of course we still have to wait for the iOS App Store dance, but hopefully this 
will be fixed, soon.

/D
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


Re: Korean?

2024-03-11 Thread Dirk Hohndel via subsurface
I was giving it a 2% chance of fixing it - but I mainly assumed that it would 
allow me understand what the heck was going on.
I'm pretty sure it has something to do with the specific languages that iOS 
tells you it has available and that somehow seriously confusing our code.

We'll see when you send the log.

/D

> On Mar 11, 2024, at 15:58, tormento wrote:
> 
> Nope it didn’t fix.
> 
> I will send the log file.
> 
> Il giorno lun 11 mar 2024 alle 01:28 Dirk Hohndel via subsurface 
>  <mailto:subsurface@subsurface-divelog.org>> ha scritto:
>> I created a new test build that should hopefully get approved for TestFlight 
>> soon (look for 6.0.5118.2).
>> If you could try that one, let me know if it fixes things, and if it doesn't 
>> fix things, create a support request from within the app so I get to see the 
>> log file...
>> 
>> Thanks
>> 
>> /D
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


Re: Korean?

2024-03-10 Thread Dirk Hohndel via subsurface
I created a new test build that should hopefully get approved for TestFlight 
soon (look for 6.0.5118.2).
If you could try that one, let me know if it fixes things, and if it doesn't 
fix things, create a support request from within the app so I get to see the 
log file...

Thanks

/D

> On Mar 8, 2024, at 23:45, tormento via subsurface 
>  wrote:
> 
> The last TestFlight build opens in Korean!
> 
> How can I reset language without knowing a single word?
> 
> Thanks,
> Alberto
> ___
> subsurface mailing list -- subsurface@subsurface-divelog.org
> To unsubscribe send an email to subsurface-le...@subsurface-divelog.org

___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


Re: Typo in the about widget?

2024-02-24 Thread Dirk Hohndel via subsurface
This is simply a sign that I needed to run the "update source strings" script 
again after the last few changes were made.

I just did that and merged the change - so Transifex should show a few more new 
strings.

/D

> On Feb 24, 2024, at 01:31, Salvador Cuñat via subsurface 
>  wrote:
> 
> Hi Michael.
> 
> The "Contribute" string in the recently added button to the about widget 
> doesn't appear in Transifex to translate.
> 
> 
> 
> 
> May be there is a typo in this line:
> 
> desktop-widgets/about.ui:97:C&ontribute
> 
> But I'm not sure about it.
> 
> Best regards.
> 
> Salva.
> ___
> subsurface mailing list -- subsurface@subsurface-divelog.org
> To unsubscribe send an email to subsurface-le...@subsurface-divelog.org

___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


Re: More mailing list fun

2024-02-23 Thread Dirk Hohndel via subsurface

Hi Jeroen,

> On Feb 23, 2024, at 15:14, Jeroen Massar  wrote:
>> 
>> I'll spare you more of the idiotic details and the rest of the 
>> self-inflicted pain, but I'll mention that we should now in theory have a 
>> great brand new mail server, running at a Hetzner data center in Europe, 
>> with a (**knocks wood**) clean IP address that is MINE to keep and control.
> 
> It even came in on IPv6 ;)

Yeah, one of the surprising things in this move has been that IPv6 from Hetzner 
has been gladly accepted by all the large mail providers. From my previous 
hoster I could never reliably get IPv6 delivery to work.

> Keep in mind that Hetzner has rather busy address space with a large 
> diversity of customers: https://bgp.tools/prefix/5.75.128.0/17#dns

Oh yes, without a doubt. I think my point was that Hetzner appears to do a good 
job going after bad actors in their prefix. And that's what kept biting me in 
the past. Not bad behavior of my server, but bad behavior in the "neighborhood" 
and not enough willingness of the hoster to do something about it.

>> As a result, these emails now are delivered by Mailman3
> 
> Check if you already have ARC options: 
> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/arc_sign.html
> One really wants to enable that due to Google.

I hadn't done that, yet. I was under the impression the SPF, DKIM, and all that 
announced via DMARC was enough.
I guess there's yet another thing to do ¯\_(ツ)_/¯

> As the body is changed (the mailinglist notice at the bottom), the original 
> DKIM header is broken, ARC will say that the original header was fine at that 
> point, and then show that it got resigned with the subsurface DKIM key.

Well - but since I am re-signing the emails after all modifications, and since 
I am doing the DMARC mangling to have the email go out from the mailing list 
address - should the email have a correct DKIM header?
In other words - when you receive the message, do you see a correct DKIM header?
I got myself spare email accounts at several of the large freeman hosters and 
subscribed them to the mailing list and they all looked fine...

> In an extreme case (if deliveries fail or scoring is affected) you might have 
> to enable 'munge_from' as per:
> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html

That's what we are doing.


> [..]
>> I really do hope that this will be the end of my sysadminning email problems 
>> for a little while.
> 
> In case there are further issues, do not hesitate to shout out and we can 
> have a poke at it on how to resolve it.

I do appreciate the offer to help!

And I'd appreciate it especially if you could look at this response email 
(which I intentionally only sent to the mailing list so that you only get it 
via Mailman, not directly).
As I said above, it seems that for my accounts at gmail, outlook, etc, these 
last few emails looked fine.

(and yes, that took a few tried - I of course created a test mail list that 
contained all of these canary accounts)

/D___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


More mailing list fun

2024-02-23 Thread Dirk Hohndel via subsurface

I know why I want to run my own mail server. It's all about control and not 
being the product that Google and others sell to their customers.
Yet, there are moments when I question my sanity with all this.

I'll spare you more of the idiotic details and the rest of the self-inflicted 
pain, but I'll mention that we should now in theory have a great brand new mail 
server, running at a Hetzner data center in Europe, with a (**knocks wood**) 
clean IP address that is MINE to keep and control.

(* insert regular THANK YOU to the folks sponsoring me / Subsurface... Hetzner 
is a lot more expensive than other hosters, but so far it appears to be worth 
the money *)

As a result, these emails now are delivered by Mailman3 - which means there's a 
new URL for the mailing list management: https://mailman.subsurface-divelog.org/

All accounts should have seamlessly ported over - but if you need to make any 
changes, you'll need to create a new account on that system.
I also ported the archives, but the archive URLs are of course different. For 
now I am keeping the old archives at 
http://lists.subsurface-divelog.org/pipermail/subsurface/ online, but over time 
I'm planning to drop those.

The usual request: I KNOW that I broke stuff (including losing a couple of days 
worth of email because I fat-fingered a command... if you are waiting for a 
response from me on something, please resend).
But I'd also love to hear if any of these emails get marked as spam, if you can 
access the new website, etc.
And anything else that I might have messed up.

I really do hope that this will be the end of my sysadminning email problems 
for a little while.

But then, that's not how things usually turn out for me.

/D___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org


un-planned developer list downtime

2024-02-21 Thread Dirk Hohndel via subsurface


It took me a couple of days to notice that the main MX server to the Subsurface 
domain was misconfigured.

Some of you may have seen bounces of their messages to this mailing list (or 
other Subsurface addresses). If that was the case, please resend.
Or better yet, maybe resend tomorrow (as I want to make sure everything is 
actually working as intended -- since I needed to work on this anyway (AGAIN), 
I did the long overdue Mailman3 upgrade)


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


Re: signed Windows installer

2024-02-10 Thread Dirk Hohndel via subsurface



On February 10, 2024 3:14:41 AM PST, Michael Keller  wrote:
>Hi Dirk.
>
>> The weird news: when I then try to install this, I STILL get the weird 
>> "don't install this" warning and have to click on "More..." before I am 
>> offered to override that. And I don't understand why since this is signed 
>> with a valid code signing certificate (which it then tells you after you 
>> went through the scare-dialog.
>
>
>The installer seems to be working fine, and without any scary warnings on my 
>Windows VM:
>
>
>
>Did you uninstall any previous versions of Subsurface before running the 
>installer?

No I did not.
I didn't think that Windows would care about that...

I do have a VM that I haven't used in ages. I'll try there as well

Thanks

/D

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


signed Windows installer

2024-02-09 Thread Dirk Hohndel via subsurface

The good news: the Windows installer that you can download as of two minutes 
ago as the Current build (so 5082) is signed.
The odd news: it's signed by my consulting company that I use to deal with the 
tax consequences of accepting donations (as that company used the donations 
money to buy the certificate). So it will say signed by DH Consulting (instead 
of Subsurface).
The weird news: when I then try to install this, I STILL get the weird "don't 
install this" warning and have to click on "More..." before I am offered to 
override that. And I don't understand why since this is signed with a valid 
code signing certificate (which it then tells you after you went through the 
scare-dialog.

I'd love to have a couple more experienced Windows people try this and double 
check that I got the signing right.

After that I need to add language to the Current Release page that explains to 
expect a binary signed by DH Consulting. 🤷🏼‍♂️

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


Re: the new website is live

2024-02-07 Thread Dirk Hohndel via subsurface
Wonchan,

The website has been live in the Korean version since yesterday :)

So please, go ahead, review!

Thank you

/D

> On Feb 7, 2024, at 09:15, Wonchan Lee  wrote:
> 
> Hello, all
> 
> In general, the following were left untranslated:
> 
> (1) Proper nouns (names of people, products and companies, etc.)
> 
> (2) Words that are familiar to Koreans and do not need to be translated, or 
> that would be awkward to translate.
> 
> Of course, the translation was done without considering the context in which 
> each word is used on the actual website. Therefore, there may be some 
> inappropriate parts. However, once the Korean version website goes live, I 
> will go through the entire website and correct any awkward parts.
> 
> 
> Thank you.
> 
> Regards,
> Wonchan Lee
> 
> 
> 
> On Wed, Feb 7, 2024 at 10:10 PM Dirk Hohndel  wrote:
>> I believe Lee Wonchan decided to leave a few terms in their original - Home 
>> and Homepage were two that I found. And of course things like names or 
>> product/project names.
>> 
>> I don't know what the "standard" is for these things
>> 
>> /D
>> 
>> > On Feb 7, 2024, at 02:11, Robert.Helling  wrote:
>> > 
>> > 
>> > 
>> >> On 6. Feb 2024, at 20:41, Dirk Hohndel  wrote:
>> >> 
>> >> I do think that the website in Korean looks cool...
>> > 
>> > Indeed. However:
>> 
>> > 
>> > 
>> > Best
>> > Robert
>> 

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


Re: the new website is live

2024-02-07 Thread Dirk Hohndel via subsurface
I believe Lee Wonchan decided to leave a few terms in their original - Home and 
Homepage were two that I found. And of course things like names or 
product/project names.

I don't know what the "standard" is for these things

/D

> On Feb 7, 2024, at 02:11, Robert.Helling  wrote:
> 
> 
> 
>> On 6. Feb 2024, at 20:41, Dirk Hohndel  wrote:
>> 
>> I do think that the website in Korean looks cool...
> 
> Indeed. However:

> 
> 
> Best
> Robert

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


Re: Test Email - New SMTP End Point

2024-02-06 Thread Dirk Hohndel via subsurface


> On Feb 1, 2024, at 06:58, Miika Turkia  wrote:
> 
> On Thu, Feb 1, 2024 at 4:48 PM Dirk Hohndel via subsurface 
>  <mailto:subsurface@subsurface-divelog.org>> wrote:
>> 
>> I know, we all hate to receive test emails. I would love to hear from those 
>> of you for whom this ended up in spam or any other oddity that you observed.
> 
> Sorry to disappoint, but Gmail received properly into inbox :D

Actually - Gmail didn't disappoint at all. After a few days all emails sent 
from the mailing list to gmail addresses started bouncing.
Because apparently at THAT point we were identified as a mass mail spammer by 
the #1 mass mail spammer in the industry.

It's a race to the bottom. Who is worse? Microsoft or Google? I'll go with 
"yes, both".

Anyway, I once again tweaked the settings. Now Gmail addresses get delivered 
from my old host, everything else gets delivered via Amazon-SES.

(and yes, it took me longer than it should have to notice this because of the 
way that Amazon-SES handled the bounces... they ended up getting caught in a 
filter and not being delivered to my inbox)

/D

PS: I hate that so much of the traffic on this mailing list isn't about 
Subsurface but about nonsense like this.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: the new website is live

2024-02-06 Thread Dirk Hohndel via subsurface



> On Feb 6, 2024, at 11:06, Peter Zaal wrote:
> 
> 
> Can't blame you, as said I misinterpreted it myself also at first.
> Just tested it with all sorts of combinations, and it is working great now!
> Thanks so much for being persistent as well ;).


Woot! Glad it's working now.

We have five completed translations now that are deployed. I'm glad that users 
with those language preferences will get the right page by default.
(and yes, I do think that the website in Korean looks cool...)

/D

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


Re: the new website is live

2024-02-05 Thread Dirk Hohndel via subsurface

Hi Peter!

> On Feb 5, 2024, at 13:32, Peter wrote:
> 
>>> 
>>> Both Edge and Chrome (on my Windows) did not open the local language pages 
>>> (cookies deleted etc). But when I started the browser in 
>>> In-Private/Incognito modus, then it did show the local pages! There is a 
>>> difference in the Accept-Language header!
>>> In in-private/incogito mode it is: "Accept-Language: nl", and in normal 
>>> mode it is "Accept-Language: nl,en;q=0.9,en-US;q=0.8,nl-NL;q=0.7" (Chrome) 
>>> and "Accept-Language: nl,en;q=0.9,en-GB;q=0.8,en-US;q=0.7" (Edge). So it 
>>> looks like the quality (q) value is messing up things and not handled 
>>> correctly server-side.
>> 
>> My understanding of the standard is that what you send is "I take Dutch and 
>> English as my preference" - but the order does NOT imply preference.
>> 
>> See https://www.rfc-editor.org/rfc/rfc9110#field.accept-language
>> 
>> 
>> It appears that the Flask backend that I am using treats the standard more 
>> literally:
>> In other words, according to the standard as written in the RFC you are 
>> getting what you are asking for "either Dutch or English, whichever you want 
>> to give me -- but I prefer en_US (with quality 0.8) over nl_NL (quality 
>> 0.7)".
> 
> Yes, and nl (with quality 1, since no value) should be preferred over en with 
> quality 0.9.
> I misread this myself at first, but the values are comma separated, and the q 
> value is after the language code.

I read the standard differently - but that might be my mistake; the term 
language-range is confusing as used here. 
 
>>> Accept-Language: nl,en;q=0.9,en-US;q=0.8,nl-NL;q=0.7

I read this as 

nl,en - both with q=0.9
en-US with quality 0.8
nl-NL with quality 0.7

But I think you are right, having re-read the RFC. This should be

nl (with implicit q=1.0)
en with q=0.9
etc.

Now, having said all that - I of course don't implement my own parsing, I'm 
using a python-werkzeug function to determine the best match.
And re-reading THAT documentation, I think I know why we fail:

For a website that offers languages = ["en","de_DE","es_ES","nl_NL"] your 
listing has a rather unintended effect:
"nl" isn't offered. but "en" is ahead of "nl-NL" in quality. So it picks "en".
I'll need to play with this to see what settings on my end could improve the 
outcome. Maybe in the language list we don't include the country spec.
Thankfully I can use curl to pretend to be your browser.

So yes, that works. But now someone with "Accept-Language: nl-NL,en;q=0.9" will 
get the wrong language. Which means I need to include both variations. Weird 
looking, but it seems to work.

Please try again, I just deployed that fix to the website.
And thanks for your persistence to make sure I get what was wrong. I misread 
how to apply the standard to the header you quoted and wasn't looking at the 
right spot for the issue.

/D



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


Re: the new website is live

2024-02-05 Thread Dirk Hohndel via subsurface


> On Feb 5, 2024, at 12:08, Peter Zaal wrote:
> 
> In the end it is not so much on the OS, as it is on what headers a specific 
> browser sends, and how the website interprets and responds to that.
> But I think (and hope) I figured out the problem.
> 
> Both Edge and Chrome (on my Windows) did not open the local language pages 
> (cookies deleted etc). But when I started the browser in In-Private/Incognito 
> modus, then it did show the local pages! There is a difference in the 
> Accept-Language header!
> In in-private/incogito mode it is: "Accept-Language: nl", and in normal mode 
> it is "Accept-Language: nl,en;q=0.9,en-US;q=0.8,nl-NL;q=0.7" (Chrome) and 
> "Accept-Language: nl,en;q=0.9,en-GB;q=0.8,en-US;q=0.7" (Edge). So it looks 
> like the quality (q) value is messing up things and not handled correctly 
> server-side.

My understanding of the standard is that what you send is "I take Dutch and 
English as my preference" - but the order does NOT imply preference.

See https://www.rfc-editor.org/rfc/rfc9110#field.accept-language


It appears that the Flask backend that I am using treats the standard more 
literally:
In other words, according to the standard as written in the RFC you are getting 
what you are asking for "either Dutch or English, whichever you want to give me 
-- but I prefer en_US (with quality 0.8) over nl_NL (quality 0.7)".

> Another small thing is that the local pages are using the 'full' 
> language-region code, so e.g. /nl_NL/...That is probably because that's how 
> the languages are declared in the languages array in server.py. But that 
> might be ok, in that way multiple regions are supported as well. Manually 
> entering and using only the language code also works.
> The language code now sticks, I don't know why it didn't before...

We use the full language code because we have in the past had translations for 
both de_DE and de_CH as well as pt_PT and pt_BR. To keep the door open for 
other such situations, we simply always use the full qualifier. Of course, if 
you request 'nl' you will get the 'nl_NL' translation... 

/D

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


Translations: [was: Re: the new website is live]

2024-02-05 Thread Dirk Hohndel via subsurface
Thanks, Peter!

The magic how almost always strings that get moved around are correctly 
maintained in Transifex and every once in a while get lost has always puzzled 
me.
Transifex is (from all I can tell) the best product out there for translations, 
and we are fortunate that they support open source projects by making this 
available to us completely free of charge, so I'm not complaining :)

I pulled and deployed your edits. Much appreciated.

We now have basically completed translations for Dutch, German, Croatian, and 
Spanish.
Two thirds of the way for Korean (!! - that's a first)
Half the way for Portuguese
Solid starts for French, Italian, Finnish, and Swedish.

As always - everyone should feel encouraged to join in and help.

One of the neat things that Transifex added is an "AI" button:



This of course has nothing to do with intelligence, but is instead a super 
convenient integration of machine translation. And I know from personal 
experience and from talking to a few of our other translators that this is 
really helpful to get started. It gives you a usually mediocre translation - 
but typically it then feels much easier to improve that (and make it consistent 
with the terms we use elsewhere).

So once again - everyone please feel encouraged to jump in with your native 
language (or a language that you are fluent in).

Thanks

/D



> On Feb 5, 2024, at 11:23, Peter wrote:
> 
> Yes I noticed that too. Somehow that string lost its translation.
> I’m sure I translated that string (into “Bijdragen”), but somehow that string 
> got recreated yesterday, loosing its translation.
> There are some more strings that lost their translation. Probably has 
> something to do with required changes for the website. I just translated all 
> missing dutch strings, and I’m sure they will be pulled some time soon.
>  
> Peter
>  
> Van: subsurface  > Namens Martin de Weger 
> via subsurface
>  
> The title for the contribute page 
> (https://subsurface-divelog.org/contribute/?lang=nl_NL) is still in English 
> (on my iPhone, using Safari as a browser). I don’t know if that is on 
> purpose, not yet translated or a bug. 
>  
> My translation would be “Bijdragen” or “”Ondersteunen”. Don’t know what Peter 
> would suggest. 
>  
>  
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: the new website is live

2024-02-05 Thread Dirk Hohndel via subsurface
Martin,

I'm pretty sure that you have a Transifex account and have translated in the 
past.
Please feel encouraged and empowered go in there and update things if they are 
missing.

Peter has done an incredible job getting things ready for the switchover, but 
we had a few new strings (mostly strings that I forgot to mark for translation, 
plus a few text changes) that are missing in the Dutch translation. The more 
people we have working on each of these translations, the better (IMHO)

Thanks

/D

> On Feb 5, 2024, at 09:58, Martin de Weger wrote:
> 
> The title for the contribute page 
> (https://subsurface-divelog.org/contribute/?lang=nl_NL) is still in English 
> (on my iPhone, using Safari as a browser). I don’t know if that is on 
> purpose, not yet translated or a bug. 
> 
> My translation would be “Bijdragen” or “”Ondersteunen”. Don’t know what Peter 
> would suggest. 
> 

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


Re: the new website is live

2024-02-05 Thread Dirk Hohndel via subsurface



> On Feb 5, 2024, at 03:11, Robert Helling wrote:
> 
> Just noticed: In the German version, the H1 headings are only partially 
> translated: "Documentation", "User Forum", "Bug Tracker", "Privacy Policy", 
> and "Sponsoring" are still in English (while the corresponding entries in the 
> left hand side navigation menu are translated).

Thanks for pointing that out. This unfortunately resulted in another couple of 
new strings (which surprised me since I thought we should already have those 
elsewhere), but it now should be consistently fixed.

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


Re: the new website is live

2024-02-04 Thread Dirk Hohndel via subsurface


> On Feb 4, 2024, at 15:48, Michael Keller wrote:
>> I forgot about the baked in URL. Oh well. redirect is now in place.
> 
> I think it might make sense to go through the baked in URLs and update the 
> ones that rely on a redirect on our website.
> Now that we have CICD releases this can be completed and rolled out with 
> short turnaround. :-)

Good idea

>> I'm not sure I understand what you are saying here.
>> Back then we started on the V3 manual when we had V3 in beta but V2 
>> was still the version in the app stores, so we had two different URLs.
>> Which kinda makes sense, I guess.
> 
> What I meant to say is that from the look of it the redirect was used since 
> the 
> https://subsurface-divelog.org/documentation/subsurface-mobile-v3-user-manual/
>  was introduced with the release of Subsurface-mobile 3 a couple of years ago 
> - so it's unlikely that there are still users with versions out there that 
> use the pre-redirect URL, and we can probably just update the redirect 
> instead of adding in a new one. 

I simply have both URLs working to show the same file now. And if someone still 
hopes for the old v2 user manual... well.. I don't have that anymore...

> Another thing that I noticed is that we are currently returning a default 
> error page for 404 (and possibly others) - we could replace this with 
> something more interesting / specific ('404'gone diving' anyone?).

Great idea. All we need is someone with the visual / graphics skills to do 
something fun.
That is most decidedly not me :)

/D

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


Re: the new website is live

2024-02-04 Thread Dirk Hohndel via subsurface
Taking this back to the mailing list...

> On Feb 4, 2024, at 08:44, Dirk Hohndel  wrote:
> 
>> On Feb 4, 2024, at 02:07, Peter Zaal  wrote:
>>  
>> Couple of questions and thinks I noticed:
>> - How do I actually switch to another language? I think the old site had a 
>> "en|de|nl|es" switch on top. That would be really helpful. I have no idea 
>> how to switch now. I tried to add /nl/... in the url, that worked (and the 
>> url is updated to ...?lang=nl), but it doesn't stick. As soon as I select 
>> another page it's the English version again. Also it doesn't use the browser 
>> settings; I see my browser (Edge on Windows) sending the Accept-Language: 
>> nl,en header. But most useful would be to allow the user to select itself 
>> with a language selection switch.
> 
> This is all really confusing to me - but of course I didn't test with Windows.
> Coming from a Mac or Linux box, the language preference of your browser is 
> used.
> If you don't want that, then both the /nl/ and ?lang=nl should work, and they 
> should be persistent - they are part of the browser session.
> I quite literally have two different 'profiles' on Firefox here on my Mac, 
> one sets preferred language to English, the other to German, and depending 
> with which one I go to the site, that's the language I get - and I can still 
> override this with /es/ and get Spanish... until I override it with something 
> else or close the browser tab.
> 
> I now do have a Windows box. I replaced Edge with Firefox right away, but of 
> course you can't uninstall it, so it's still there and I'll try.

Today has been a fascinating day of appreciation (for all the people stepping 
up to help out) and learning - about all kinds of weird things; most relevant 
for this conversation the wild and creative ways in which different browsers on 
different OSs do what seems to be the same thing very differently.

Long story short - I think the site should now respect your browser's language 
preference (and if it doesn't I really wanna know about it and figure out what 
headers YOUR browser sends to my server -- I have tested this with Safari, 
Firefox, Chrome, and MSFT Crap... sorry, they named it Edge for some reason... 
across macOS, Linux, and Windows (obviously not every browser on every OS, but 
at least two browsers on each of them). 

On top of that, you should now be able to simply append "?lang=CODE" with the 
appropriate language code and that will work. And of course the old "prefix the 
language code in front of the URL" thing also works.

So for someone with a German browser, 
https://subsurface-divelog.org/current-release should open the page for the 
Aktuelle "wöchentliche" Version - and using 
https://subsurface-divelog.org/nl/current-release should get them Huidige 
"wekelijkse" versie. And each subsequent link within the site will carry with 
it the corresponding language indicator. So if you once pick a language 
different than what your browser tells us it prefers, subsequently you should 
stay in that language if you follow site-internal links.

I will admit that getting this to work was decidedly NOT FUN.

Please test. Please show me examples where it's still broken. I tried very hard 
to catch all links, but I'm not 100% sure that none escaped my grep-patterns.

Thanks

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


Re: the new website is live

2024-02-04 Thread Dirk Hohndel via subsurface
Hi Michael,

> On Feb 4, 2024, at 13:07, Michael Keller wrote:
> 
> I think the 'right' way to do this will be two-pronged:
> 1. update the URL baked into the mobile application (done here:
> https://github.com/subsurface/subsurface/pull/4082)
> 2. add a redirect from the legacy URL to the new URL so users on older
> versions of the mobile application are not left high and dry.

I forgot about the baked in URL. Oh well. redirect is now in place.

> Re. 2., from the look of it this has been redirected once already, the
> URL currently baked into the application is
> https://subsurface-divelog.org/documentation/subsurface-mobile-v3-user-manual/
> - which seems to have been baked in since before the move from v2 to
> v3, so maybe we can just change the existing redirect to point to
> https://www.subsurface-divelog.org/subsurface-mobile-user-manual/

I'm not sure I understand what you are saying here.
Back then we started on the V3 manual when we had V3 in beta but V2 
was still the version in the app stores, so we had two different URLs.
Which kinda makes sense, I guess.

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


Re: the new website is live

2024-02-04 Thread Dirk Hohndel via subsurface
Hi Michael,

> On Feb 4, 2024, at 03:57, Michael Keller wrote:
> 
>> Please keep testing the site - I tried to go through the various aspects of 
>> it, but I'm sure I overlooked something. I'll also announce this in the user 
>> forum in a moment, so I expect that to get us more eyeballs.
> I suspect that one thing that went missing in the move is the 
> Subsurface-mobile manual. I just tried to open it from within the 
> application, and I am getting a 404 for 
> https://subsurface-divelog.org/subsurface-mobile-v3-user-manual/
> 

This works here - but with the 'new' URL... I need to make sure I add a 
redirect for the old URL

 https://www.subsurface-divelog.org/subsurface-mobile-user-manual/

/D

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


Re: the new website is live

2024-02-04 Thread Dirk Hohndel via subsurface
Ok, I'm out of time this morning, more this afternoon.

>> On the homepage, "Screenshot of rating, tags and other data fields" and 
>> "Screenshot of dive profile" are 404.

Fixed
>> The link to the Sponsoring page in the menu is the only link which opens a 
>> new tab. I think it would be more consistent if the link itself opens in the 
>> same tab, but maybe the links to ko-fi and github open in a new page.

Fixed

But I also notice with a few more people hitting this server that while on 
paper this should be plenty powerful (4 cores, 6G Ram), it's clearly over 
provisioned to the tilt and not all that responsive... Oh well, more to look 
into.

/D

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


Re: the new website is live

2024-02-04 Thread Dirk Hohndel via subsurface


> On Feb 4, 2024, at 07:40, Christof Arnosti  wrote:
> 
> On the homepage, "Screenshot of rating, tags and other data fields" and 
> "Screenshot of dive profile" are 404.

I got another report of that. It seems to work here and I have no idea what's 
going on, but I'll figure it out.
> In the carousel, in the Cloud section, I think it would be a good idea to 
> note that Cloud Storage is optional.

I can do that

> The link to the Sponsoring page in the menu is the only link which opens a 
> new tab. I think it would be more consistent if the link itself opens in the 
> same tab, but maybe the links to ko-fi and github open in a new page.

Yes, that's inconsistent, I'll fix that.

/D

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


the new website is live

2024-02-03 Thread Dirk Hohndel via subsurface


Thanks everyone for your help in getting this site started and debugged.
Thanks to Peter, Robert, and Salvador for providing complete translations to 
Dutch, German, and Spanish. I really appreciate your effort here. And so do our 
users in those respective languages.

Please keep testing the site - I tried to go through the various aspects of it, 
but I'm sure I overlooked something. I'll also announce this in the user forum 
in a moment, so I expect that to get us more eyeballs.


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


Re: website updates, translations, and email woes

2024-02-03 Thread Dirk Hohndel via subsurface



> On Feb 3, 2024, at 00:27, Peter Zaal  wrote:
> 
> Ok that's weird because the number of strings is different (2577 vs 2563), 
> and at least in the Dutch translations there are untranslated strings in the 
> "translations/subsurface_source.ts (master)" resource that I have translated 
> in the "subsurface4" resource long time ago.

You are correct and I answered from memory instead of actually double checking.

When Transifex more or less forced us to switch to their git integration model 
(ok, that's a bit unfair, but they made it a lot more painful to use the manual 
push/pull model and at the same time impoved their git integration so much that 
it made no sense to stick with the previous model), we apparently ended up with 
a new resource name and I completely missed that.

I now deleted the outdated resources to avoid confusing myself and others.

It is indeed translations/subsurface_source.ts (master) [[ catchy name, ain't 
it? ]] that is the correct one to translate for both desktop and mobile 
versions.

My apologies for the confusion.

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


Re: website updates, translations, and email woes

2024-02-02 Thread Dirk Hohndel via subsurface
Hi Peter,

> On Feb 1, 2024, at 14:38, Peter wrote:
> 
> I'm currently updating the Dutch translations for the new-website project,
> but I also noticed that in the subsurface project there is a resource
> "translations/subsurface_source.ts (master)". I don't think I have seen that
> before, I always used the subsurface4 resource I believe.
> Which one is the correct one?


translations/subsurface_source.ts (master) is the exact file that is used to
hold the source strings that are part of the "subsurface4" resource - i.e., 
these
are the same thing.

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


pardon yet another interruption... Subsurface updates

2024-02-01 Thread Dirk Hohndel via subsurface

Given that the new SMTP delivery path does in fact appear to make all of the 
large providers happy (we had not a single email bounce which is, frankly, 
quite a surprise to me), I have tried to add back all the people who were 
force-unsubscribed over the past two weeks.

To those of you who were excited to finally have gotten rid of this silly 
mailing list - my apologies, just drop me a line and I'll take you back off -- 
actually that's for anyone who wants to get off of this list, I'm happy to do 
this via email, no need to fight mailman

I was hoping to get the Snap version number problem solved before switching 
over the website to the new design, but that does appear somewhat more 
challenging, so I think I won't try to wait for it and do the switchover this 
weekend.

With that I'll archive / retire the GitHub.io site - but in order to not break 
links that people may have I'll try to do that with redirects (so expect some 
noise in THAT repository).


Next I want to do another "current / weekly" release - three weeks after the 
last "weekly release" 🤦🏻‍♂️ -- I held that up waiting to be able to sign the 
Windows installer. I was on a business trip this week (writing this in the 
plane back to the West Coast, actually) and while I was gone apparently the 
hardware token arrived so hopefully (time permitting) I will get that taken 
care of over the weekend as well.

Finally - I do notice that some of the people whose email provider blocked me 
from sending them email are French... maybe it was my pleas for a French 
translation of the new website that caused the problem? (just kidding)

Thanks everyone for your patience with all these distractions.

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


Re: further iterations on the release process and user experience

2024-01-15 Thread Dirk Hohndel via subsurface
Yet another iteration. I followed many of Michael's suggestions.

I'm curious what others think?

It's a bit lonely here when no one comments on the work we do. There's a few 
hundred people on this mailing list (and with the recent bout of emails, three 
unsubscribed 🤣)

None of this requires a lot of work or any understanding other than that of a 
user. I guess maybe I should ask on the User Forum.

"current / weekly" release page: https://subsurface-divelog.org/current-release/
"latest / bleeding edge" release: https://subsurface-divelog.org/latest-release/

The Ubuntu / Copr instructions are still the same on both pages - once we have 
settled on good names I'll create corresponding names for those and have 
differentiated instructions as well.

Thanks

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


Re: Update form win 10/11

2024-01-15 Thread Dirk Hohndel via subsurface
I'm surprised and mildly confused that it would update to an unsigned binary 
without complaining and making you click on a few dialogues...

But I'll admit that I don't understand at all how this is supposed to work 
exactly.. 

/D

On January 15, 2024 10:03:45 AM PST, Eric Tanguy via subsurface 
 wrote:
>___
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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


Re: further iterations on the release process and user experience

2024-01-14 Thread Dirk Hohndel via subsurface



>
>>Also, I am wondering if the iOS paragraph should be above 'Linux' -
>>this will make it show above the fold for most users, and reduce the
>>number of users posting questions after not finding it.
>
>The reason I have it on the bottom is because it doesn't really give people 
>anything. And they already get notifications from the AppStore, assuming I 
>keep my promises 😁

Oh, and I do think that the update language for the Linux distros is much 
nicer, if I may say so.

I ended up ordering an ultra cheap Windows 11 PC on Amazon. That way hopefully 
I can experiment with the Windows user experience as well.

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


Re: further iterations on the release process and user experience

2024-01-14 Thread Dirk Hohndel via subsurface


On January 14, 2024 6:16:44 PM PST, Michael Keller  wrote:
>
>
>Looking good!

Thank you

>I would probably add a link to the other page to the top of each page,
>'if you want the latest version, go [here]' / 'if you want a more
>stable version, go [here]', or else users will get locked in once they
>have bookmarked one of the pages.

There are links in the menu on the left.
But we can of course make it more explicit.

>Also, I am wondering if the iOS paragraph should be above 'Linux' -
>this will make it show above the fold for most users, and reduce the
>number of users posting questions after not finding it.

The reason I have it on the bottom is because it doesn't really give people 
anything. And they already get notifications from the AppStore, assuming I keep 
my promises 😁

>And I am wondering if it would be better to use more distinguishable
>names for the 'release tracks' than 'latest' / 'current' - I suspect
>that users will confuse these when talking about them in support
>posts. Maybe 'nightly' vs. 'weekly'?

Not a fan because I don't think those really will be the timeframes that these 
builds will happen at. Certainly not nightly.

unstable and stable ?
edge and tested ?

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


Re: further iterations on the release process and user experience

2024-01-14 Thread Dirk Hohndel via subsurface
Not being able to leave your house, a laptop and internet connection... ideal 
conditions to keep dinking around with stuff :)


> On Jan 13, 2024, at 10:53, Dirk wrote:
> 
> In order to address some of these concerns, I built a new download page and 
> some automation that keeps it updated. This happens with, at a minimum, a 1h 
> time lag so that all binaries show up at the same time; this also gives us 
> some margin of error if we merge something that fails that allows us to not 
> post a release. And of course there's a mechanism to manually point at a 
> different release.

So this should now be the https://subsurface-divelog.org/latest-release/ page - 
clearly showing that this is the Latest CICD Release.

In addition, there is a https://subsurface-divelog.org/current-release/ Current 
Release page. With the goal to iterate this more slowly - maybe once a week. 
And, now that I had the time to figure out how this can work (see above), this 
even links to a SIGNED macOS DMG.

> Finally, app signing.
> Given how painful macOS makes it to install unsigned apps, I think I'll need 
> to figure out how to sign at least the "weekly" builds. I doubt that I can 
> truly automate that, but maybe I can figure out a way to keep up with things.

Done

> As for Windows - that's a harder problem. The signing mechanisms for Windows 
> are either prohibitively expensive (even with the generous donations from 
> some of you - we are talking around $300-500  a year plus hardware cost (as I 
> would need an actual real Windows machine for this -- apparently doing this 
> in a VM no longer works) for what is essentially a blessed random number. The 
> old system that was more affordable (~$100/year) has been killed by Microsoft 
> when they started making additional requirements (including allowing signing 
> certificates only when they are on hardware keys). And as  I mentioned 
> before, I'm seeing a lot more companies release unsigned apps for Windows 
> again.
> If a better and more realistically priced solution pops up, I'll happily 
> revisit this topic.

Also, some googling and following countless broken links later... it appears 
there is a not quite as expensive option:
 https://cheapsslsecurity.com/fastssl/code-signing-certificate.html

With the required hardware token, a three year certificate is about $500 with 
shipping - so $170/yr. That is still a lot, but seems more doable. 
Now all I would need is a Windows PC 🤣

So, question to the Windows users here... how often do you see unsigned apps? 
How much of an issue is it to have the Subsurface installer not signed. As I 
keep saying, I don't use Windows myself, so it's really hard to judge for me...

Thanks

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


Re: PSA: mailing list downtime

2024-01-14 Thread Dirk Hohndel via subsurface


> On Jan 14, 2024, at 15:44, Michael Keller  wrote:
> 
> Hi Dirk.
> 
> Mail sending seems to be working. Thanks for getting this migrated.

I should have done that ages ago. Now all Subsurface infrastructure is gone 
from my house.
Five years ago (-ish) all of it was hosted at my house 😳

> I hope it wasn't too cold during the outage.

It was about 10F / -12C outside, but we managed to keep the house around 60F / 
15C.
So no, it wasn't bad.

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


Re: PSA: mailing list downtime

2024-01-14 Thread Dirk Hohndel via subsurface


> On Jan 13, 2024, at 11:37, Dirk Hohndel via subsurface 
>  wrote:
> 
> 
> Perfect timing.
> 
> The power went out. I'm running on batteries, shutting things down.
> 
> The only thing affected should be the developer mailing list, that's the one 
> thing I haven't migrated to the cloud infrastructure, yet.
> My personal email will continue to work, so if you need something (or 
> something is going down after all, beyond this mailing list), you can reach 
> me at d...@hohndel.org <mailto:d...@hohndel.org>
> 
> I'll wait for this email to go out and then shut down the server:)

Power has been back for a while, and I just completed (I hope) the move of the 
subsurface-divelog email infrastructure into the cloud.
A couple of test emails worked, the 
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface web 
interface seems to be up and running as well.
So assuming this mail goes out, I hope we're all good.

If you observe any oddities, please let me know, but this should all be pretty 
seamless.


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


PSA: mailing list downtime

2024-01-13 Thread Dirk Hohndel via subsurface

Perfect timing.

The power went out. I'm running on batteries, shutting things down.

The only thing affected should be the developer mailing list, that's the one 
thing I haven't migrated to the cloud infrastructure, yet.
My personal email will continue to work, so if you need something (or something 
is going down after all, beyond this mailing list), you can reach me at 
d...@hohndel.org 

I'll wait for this email to go out and then shut down the server:)

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


further iterations on the release process and user experience

2024-01-13 Thread Dirk Hohndel via subsurface

I have been chatting off-list with Michael but really should be having these 
conversations here.

Initial feedback on the CICD release process has been overwhelmingly positive, 
but there were a few really good pieces of criticism as well

- the GitHub release page is not very user friendly and feels far more like 
something targeting developers, not end users / divers
- in the same context, it's hard for some of our users to figure out which 
binaries to download - which one is the Windows installer, which one is for 
Android, etc
- depending on how many things get merged / pushed, this process creates a LOT 
of new releases which most people will not want to upgrade to all the time
- unsigned binaries are far less convenient than signed binaries, especially on 
macOS, but also on Windows
- it would be nice to get better update notifications in the apps, and to 
include Android in that list (as it no longer gets store notifications)
- what about iOS?

In order to address some of these concerns, I built a new download page and 
some automation that keeps it updated. This happens with, at a minimum, a 1h 
time lag so that all binaries show up at the same time; this also gives us some 
margin of error if we merge something that fails that allows us to not post a 
release. And of course there's a mechanism to manually point at a different 
release.

You can see the current version of this download page here: 
https://subsurface-divelog.org/current-release/ 
This is NOT linked into the overall website, yet, as I wanted to collect a bit 
more feedback, first.
(and yes, I am not a good web designer... tell me something I don't know)

This should address the first couple of concerns listed above.

To deal with the third one, I am thinking through options to semi-automatically 
create weekly releases with a different landing page (that clearly identifies 
these as "weekly", but is otherwise very similar to the page above). And I'm 
hoping to find a rhythm to also update the iOS app roughly in that cadence.

In this context I am hoping to overhaul the update mechanism for the apps (and 
add the mobile apps to the mix) and set things up so people can pick if they 
want the water-hose or the weekly update reminders. That hasn't happened, yet, 
and obviously will also require some changes in the apps (while at the same 
time not breaking older apps). So this may take a little longer :)

Finally, app signing.
Given how painful macOS makes it to install unsigned apps, I think I'll need to 
figure out how to sign at least the "weekly" builds. I doubt that I can truly 
automate that, but maybe I can figure out a way to keep up with things.
As for Windows - that's a harder problem. The signing mechanisms for Windows 
are either prohibitively expensive (even with the generous donations from some 
of you - we are talking around $300-500  a year plus hardware cost (as I would 
need an actual real Windows machine for this -- apparently doing this in a VM 
no longer works) for what is essentially a blessed random number. The old 
system that was more affordable (~$100/year) has been killed by Microsoft when 
they started making additional requirements (including allowing signing 
certificates only when they are on hardware keys). And as  I mentioned before, 
I'm seeing a lot more companies release unsigned apps for Windows again.
If a better and more realistically priced solution pops up, I'll happily 
revisit this topic.


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


Re: MXE shipping ancient mdbtools version

2024-01-13 Thread Dirk Hohndel via subsurface
We built 64bit and 32bit binaries for quite a while, but anymore, so I think 
those should be disabled.

Ironically, I used to simply spot-create a massive VM on AWS (think 64 cores 
and many GB of RAM) which would then do the build fairly quickly and be 
terminated afterwards. That made dealing with that build feasible.
I wonder if they would complete within the time limits in GitHub these days. A 
few years ago they definitely did not.
I experimented with a two stage build, but that was just horrible to work with.

/D

On January 13, 2024 3:30:42 AM PST, "Salvador Cuñat"  
wrote:
>Hi Michael.
>
>El vie, 12 ene 2024 a las 2:32, Michael Keller () escribió:
>
>>
>> No problem, I can hold off on that until you let me know.
>>
>
>I've finally been able to build the image and works fine.  Attached is the
>patch to apply taken from the github PR. I don't know too much about MXE's
>internals but the patch has passed all recommended tests from MXE site,
>downloads the correct tar file, correctly checks for version, and correctly
>checks file's checksum.
>
>BTW, I've noticed we are building the image with shared libraries for both
>triplets x86_64-w64-mingw32 and i686-w64-mingw32. But then we only use
>those from x86_64-w64-mingw32.
>
>i686-w64 binaries add approx. 3GB to the image and probably 1 hour to the
>build, depending on the machine, off course.  Maybe @Dirk Hohndel
> remember why these are built or maybe they are just a
>dangling blast from the past ;-).
>
>If it's the last case, I think they can be safely removed from the image
>build.
>
>Best regards.
>
>Salva.

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


Re: crash in QMLManager destructor

2024-01-09 Thread Dirk Hohndel via subsurface
> 
> Thank you to all of you who tested and sent me updates, on list and off.
> 
> I decided to push this one out as the next product version. The previous one 
> in the AppStore was really getting fairly old.
> If we find more bugs I am now once again set up to be able to fairly quickly 
> make updated releases ("quickly" of course being gated by the speed of 
> Apple's reviews).


And just over an hour later (but after I went to bed) this already has 
happened. So the new version is "out in the wild" now 😁

So everyone should have access to this version.

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


Re: MXE shipping ancient mdbtools version

2024-01-09 Thread Dirk Hohndel via subsurface
Good Morning Salvador!

> On Jan 8, 2024, at 22:43, Salvador Cuñat wrote:
> 
> Have just realized MXE is shipping ancient mdbtools version 0.7.1 which dates 
> back 10/2013.

That is quite an antique. Wow.

> I'll try to get this solved upstream, but don't know how long can it take.

The MXE community has been reasonably responsive when I had issues in the past 
- but often the answer might be "send patches" (which it looks like you have).

> Meanwhile you can apply attached patch to the mxe building docker image. The 
> good part is you don't need to rebuild the full image, just mdbtools after 
> patching.  An example workflow would be:
> 
> - place the patch file in local folder accessible to running container, eg 
> src/win32 (folder parallel to subsurface source)
> 
> - load the image: (assumed running from same src folder previously said)
> docker run -v "$PWD"/win32:/win/win32 -v "$PWD"/subsurface:/win/subsurface 
> --name=mybuilder -w /win -d subsurface/mxe-build-container:3.0.1 /bin/sleep 
> 60m
> 
> - patch the mxe sources
> docker exec -t mybuilder patch /win/mxe/src/mdbtools.mk  
> /win/win32/mdbtools2.patch
> 
> - redownload and build mdbtools inside the running container
> docker exec -t mybuilder bash -c "cd /win/mxe && make -j 2 download-mdbtools"
> 
> docker exec -t mybuilder bash -c "cd /win/mxe && make 
> MXE_TARGETS=x86_64-w64-mingw32.static mdbtools -j 1"
> 
> - save the image of the container with a new tag, eg:
> docker commit -a "Salvador Cuñat salvador.cu...@gmail.com 
> " -m "Apply mdbtools patch to get version 
> v1.0.0 and rebuild package" mybuilder subsurface/mxe-build-container:3.0.2
> 
> If rebuilding the full image, the patch should be applied while building the 
> Dockerfile, **after** checking out the desired MXE sha.

I'll look into this to get an updated build container ready (this might take a 
while). 
Or I can give you write permission to the docker hub and you can help us 
maintain that image. Would you be interested in this?

/D

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


Re: crash in QMLManager destructor

2024-01-08 Thread Dirk Hohndel via subsurface
Thank you to all of you who tested and sent me updates, on list and off.

I decided to push this one out as the next product version. The previous one in 
the AppStore was really getting fairly old.
If we find more bugs I am now once again set up to be able to fairly quickly 
make updated releases ("quickly" of course being gated by the speed of Apple's 
reviews).

/D

> On Jan 8, 2024, at 20:46, Doug Junkins wrote:
> 
> I have confirmed as well that this fixes the crash on exit I was able to 
> reproduce earlier today.
> 
> -Doug
> 
>> On Jan 8, 2024, at 6:03 PM, Dirk Hohndel via subsurface 
>>  wrote:
>> 
>> 
>> 
>>> On Jan 8, 2024, at 15:39, Dirk  wrote:
>>> 
>>> So I am somewhat optimistic that once the next build gets approved, we'll 
>>> have this one fixed.
>> 
>> 2.5h - that's not bad at all.
>> 
>> You should see a TestFlight notification (if you are part of the beta 
>> testers for iOS).
>> 
>> /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: crash in QMLManager destructor

2024-01-08 Thread Dirk Hohndel via subsurface



> On Jan 8, 2024, at 15:39, Dirk  wrote:
> 
> So I am somewhat optimistic that once the next build gets approved, we'll 
> have this one fixed.

2.5h - that's not bad at all.

You should see a TestFlight notification (if you are part of the beta testers 
for iOS).

/D

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


Re: crash in QMLManager destructor

2024-01-08 Thread Dirk Hohndel via subsurface

>> On Jan 8, 2024, at 13:28, Dirk wrote:
>> 
>> 
>> IosShare::~IosShare() {
>> [(id)self dealloc];
>> }
> 
> 
> Test build with empty destructor coming up. Of course I never know how long 
> Apple will sit on it before it shows up in TestFlight.


I managed to beat Xcode into submission to allow me to locally debug this with 
my iPad.
I first was able to reproduce the crash (thanks to those who gave detailed 
explanations when it would happen).
And then removed the dealloc call and now I cannot reproduce the crash.

So I am somewhat optimistic that once the next build gets approved, we'll have 
this one fixed.

Thanks for all the help tracking this down!

/D

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


Re: crash in QMLManager destructor

2024-01-08 Thread Dirk Hohndel via subsurface


> On Jan 8, 2024, at 13:28, Dirk wrote:
> 
> 
> IosShare::~IosShare() {
> [(id)self dealloc];
> }


Test build with empty destructor coming up. Of course I never know how long 
Apple will sit on it before it shows up in TestFlight.

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


Re: crash in QMLManager destructor

2024-01-08 Thread Dirk Hohndel via subsurface


> On Jan 8, 2024, at 13:26, Dirk Hohndel  wrote:
> 
> 
> 
>> On Jan 8, 2024, at 13:20, Berthold Stoeger wrote:
>> 
>> On Montag, 8. Jänner 2024 22:15:24 CET Dirk Hohndel wrote:
>> 
>>>5d78:  ARM64_RELOC_BRANCH26 __ZN8IosShareD1Ev
>> 
>> Could you show the disassembly of that? Perhaps a tail-call to 
>> std::terminate and therefore it doesn't show up in the stack trace?
>> 
> 
> of course IosShare is that lovely ObjC++ thing that I did in response to 
> stuff I found on the Qt Forum. And I most definitely did that blind because I 
> can't even read that code and fully make sense of it...
> 
> Thiago, is that something that makes sense to you?
> 
> here's the disassembled code and yes, it does call terminate...
> 
> 0070 :
>  70: a9be4ff4  stp x20, x19, [sp, #-32]!
>  74: a9017bfd  stp x29, x30, [sp, #16]
>  78: 910043fd  add x29, sp, #16
>  7c: aa0003f3  mov x19, x0
>  80: f940  ldr x0, [x0]
>  84: 9400  bl  0x84 
>0084:  ARM64_RELOC_BRANCH26 _objc_msgSend$dealloc
>  88: aa1303e0  mov x0, x19
>  8c: a9417bfd  ldp x29, x30, [sp, #16]
>  90: a8c24ff4  ldp x20, x19, [sp], #32
>  94: d65f03c0  ret
>  98: 9400  bl  0x98 
>0098:  ARM64_RELOC_BRANCH26 ___clang_call_terminate
> 

which of course (snort) is this:


IosShare::~IosShare() {
[(id)self dealloc];
}

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


Re: crash in QMLManager destructor

2024-01-08 Thread Dirk Hohndel via subsurface


> On Jan 8, 2024, at 13:20, Berthold Stoeger wrote:
> 
> On Montag, 8. Jänner 2024 22:15:24 CET Dirk Hohndel wrote:
> 
> > 5d78:  ARM64_RELOC_BRANCH26 __ZN8IosShareD1Ev
> 
> Could you show the disassembly of that? Perhaps a tail-call to std::terminate 
> and therefore it doesn't show up in the stack trace?
> 

of course IosShare is that lovely ObjC++ thing that I did in response to stuff 
I found on the Qt Forum. And I most definitely did that blind because I can't 
even read that code and fully make sense of it...

Thiago, is that something that makes sense to you?

here's the disassembled code and yes, it does call terminate...

0070 :
  70: a9be4ff4  stp x20, x19, [sp, #-32]!
  74: a9017bfd  stp x29, x30, [sp, #16]
  78: 910043fd  add x29, sp, #16
  7c: aa0003f3  mov x19, x0
  80: f940  ldr x0, [x0]
  84: 9400  bl  0x84 
0084:  ARM64_RELOC_BRANCH26 _objc_msgSend$dealloc
  88: aa1303e0  mov x0, x19
  8c: a9417bfd  ldp x29, x30, [sp, #16]
  90: a8c24ff4  ldp x20, x19, [sp], #32
  94: d65f03c0  ret
  98: 9400  bl  0x98 
0098:  ARM64_RELOC_BRANCH26 ___clang_call_terminate

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


Re: crash in QMLManager destructor

2024-01-08 Thread Dirk Hohndel via subsurface



> On Jan 8, 2024, at 13:04, Linus Torvalds wrote:
> 
> On Mon, 8 Jan 2024 at 12:18, Dirk Hohndel via subsurface
>  wrote:
> 
> "objdump -d" is horrible at disassembly.

no kidding.

> For some unfathomable reason, it doesn't look at relocation
> information, so when it disassembles any instruction with relocations,
> the end result is garbage.
> 
> And no, adding "-r" to make it show relocation information isn't much
> better. The disassembly is still garbage, but there will now be an
> extra line that basically says "if I wasn't showing you garbage, I
> would use this line to tell you what the garbage should have been".
> 
> So then you can - manually - use that relocation information to show
> what the disassembly should have been.

see below

> is the call chain result from here:
> 
>   8   Subsurface-mobile  0x00010027589c
> QMLManager::~QMLManager() + 68 (qmlmanager.cpp:608)
> 
> but that's really just the return point from that
> 
>>5d78: 9400 bl 0x5d78 
> 
> and that's very much an example of the whole "objdump is showing
> garbage". That function isn't calling itself, but that's what objdump
> -d shows, because it doesn't look at the reloc info.
> 
> Anyway, I think this has probably been compiled with some sanitizer.
> With "-r" to objdump, at least we'd see what the call target for that
> "bl" instruction is, which might give some clue.

5d60: 3468  cbz w8, 0x5d6c 
5d64: 9103e260  add x0, x19, #248
5d68: 9400  bl  0x5d68 
5d68:  ARM64_RELOC_BRANCH26 
__ZN11QFileDevice5closeEv
5d6c: 9008  adrpx8, 0x5000 
5d6c:  ARM64_RELOC_PAGE21   
__ZN10QMLManager10m_instanceE
5d70: f900011f  str xzr, [x8]
5d70:  ARM64_RELOC_PAGEOFF12
__ZN10QMLManager10m_instanceE
5d74: 91044260  add x0, x19, #272
5d78: 9400  bl  0x5d78 
5d78:  ARM64_RELOC_BRANCH26 __ZN8IosShareD1Ev
5d7c: 9103e260  add x0, x19, #248
5d80: 9400  bl  0x5d80 
5d80:  ARM64_RELOC_BRANCH26 __ZN5QFileD1Ev
 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: crash in QMLManager destructor

2024-01-08 Thread Dirk Hohndel via subsurface

> On Jan 8, 2024, at 10:29, Berthold Stoeger  wrote:
> 
> Hi Dirk,
> 
> On Montag, 8. Jänner 2024 18:10:45 CET Dirk Hohndel via subsurface wrote:
> 
> > So it seems like the crash happening on close on iOS is line 608 in
> > qmlmanager.cpp - so at the end of the QMLManager destructor.
> 
> This doesn't happen for me (mobile-on-desktop), so I'm not sure that I can 
> help. Can you send me the disassembly of QMLManager::~QMLManager()?
> 
> E.g. in gdb: "disassemble QMLManager::~QMLManager()" Note that for me that 
> doesn't give the actual function, but only a stub:
> 
> Dump of assembler code for function _ZN10QMLManagerD0Ev:
>0x0014b1e0 <+0>: endbr64
>0x0014b1e4 <+4>: push   %rbx
>0x0014b1e5 <+5>: mov%rdi,%rbx
>0x0014b1e8 <+8>: call   0x14af80 <_ZN10QMLManagerD2Ev>
>0x0014b1ed <+13>:mov%rbx,%rdi
>0x0014b1f0 <+16>:mov$0xf8,%esi
>0x0014b1f5 <+21>:pop%rbx
>0x0014b1f6 <+22>:jmp0x104510 <_ZdlPvm@plt>
> End of assembler dump.
> 
> The actual function is then in 0x14af80, for whatever reason.

Now I need to figure out how to do that in Xcode ...

Hmmm. Can't find an obvious way when I open the stack trace. It just shows the 
C++ code.
Online I find suggestions how to do that when live-debugging an app on an iOS 
device. So I guess I DO need to try and reproduce this on my iPad. So far I 
wasn't able to...

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


Re: iOS / TestFlight (Dirk Hohndel)

2024-01-08 Thread Dirk Hohndel via subsurface
Thank you so much!
The download from BLE is the big thing I still wait to hear about.

And ideas how to solve the crash on exit :(

/D

> On Jan 8, 2024, at 09:56, Hartley wrote:
> 
> I've done some rudimentary testing on my iphone 13 mini running iOS 17.1.2.  
> No issues, but I haven't tried downloading from a dive computer yet.
> 
> * loaded from the cloud
> * edited a dive
> * uploaded back to the cloud
> * viewed some existing dives in landscape & portrait mode.
> 
> ...Hartley Horwitz

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


crash in QMLManager destructor

2024-01-08 Thread Dirk Hohndel via subsurface
Hi again

So it seems like the crash happening on close on iOS is line 608 in 
qmlmanager.cpp - so at the end of the QMLManager destructor.

Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib  0x0001d563101c __pthread_kill + 8 
(:-1)
1   libsystem_pthread.dylib 0x0001f7b7d680 pthread_kill + 268 
(pthread.c:1681)
2   libsystem_c.dylib   0x000196191b90 abort + 180 
(abort.c:118)
3   libc++abi.dylib 0x0001f7aaa660 abort_message + 132 
(abort_message.cpp:78)
4   libc++abi.dylib 0x0001f7a9a62c 
demangling_terminate_handler() + 348 (cxa_default_handlers.cpp:77)
5   libobjc.A.dylib 0x00018652ad34 _objc_terminate() + 
144 (objc-exception.mm:496)
6   libc++abi.dylib 0x0001f7aa9a24 
std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59)
7   libc++abi.dylib 0x0001f7aa99c8 std::terminate() + 
56 (cxa_handlers.cpp:88)
8   Subsurface-mobile   0x00010027589c 
QMLManager::~QMLManager() + 68 (qmlmanager.cpp:608)
9   Subsurface-mobile   0x0001001620e4 
QQmlPrivate::QQmlElement::~QQmlElement() + 12 (qqmlprivate.h:144)
10  Subsurface-mobile   0x0001001620e4 
QQmlPrivate::QQmlElement::~QQmlElement() + 12 (qqmlprivate.h:142)
11  Subsurface-mobile   0x0001001620e4 
QQmlPrivate::QQmlElement::~QQmlElement() + 28 (qqmlprivate.h:142)
12  Subsurface-mobile   0x000101759b08 
QObjectPrivate::deleteChildren() + 260
13  Subsurface-mobile   0x000101759844 QObject::~QObject() 
+ 1968
14  Subsurface-mobile   0x000100d9e4e8 
QQuickItem::~QQuickItem() + 984
15  Subsurface-mobile   0x000100c9d45c 
QQuickContentItem::~QQuickContentItem() + 12
16  Subsurface-mobile   0x000101759b08 
QObjectPrivate::deleteChildren() + 260
17  Subsurface-mobile   0x000101759844 QObject::~QObject() 
+ 1968
18  Subsurface-mobile   0x000100d9e4e8 
QQuickItem::~QQuickItem() + 984
19  Subsurface-mobile   0x000100dcce68 
QQuickRootItem::~QQuickRootItem() + 12
20  Subsurface-mobile   0x000100dc0fec 
QQuickWindow::~QQuickWindow() + 216
21  Subsurface-mobile   0x000100be2b8c 
QQmlPrivate::QQmlElement::~QQmlElement() + 56
22  Subsurface-mobile   0x0001014939bc 
QQmlApplicationEngine::~QQmlApplicationEngine() + 168
23  Subsurface-mobile   0x00010016153c 
run_mobile_ui(double) + 3468 (subsurface-helper.cpp:190)
24  Subsurface-mobile   0x000100160330 main + 816 
(subsurface-mobile-main.cpp:95)
25  Subsurface-mobile   0x00010061bb50 
user_main_trampoline() + 280
26  Subsurface-mobile   0x00010061b990 
+[QIOSApplicationStateTracker applicationDidFinishLaunching:] + 1120
27  ??? 0x0002 0x0 + 2


That's of course a bit frustrating (because that thing's a monster), but it may 
help us to track down what's going on.

Of course, sadly, the number of Qt / QML experts in the developer team has 
dwindled quite a bit. And our C++ rock star developer is crazy busy at his day 
job. So I'm not sure how much hope I have that this can be fixed, quickly.

It looks to me like we are reasonably walking down the stack of objects, trying 
to destroy/free them, and then things go poorly. In run_mobile_ui (stack frame 
23) we have finished the app; qApp->exec() has returned and it now starts 
cleaning up the local objects. And the QMLApplicationEngine that owns the QML 
app just walks down it's objects...
Of course, since we have completed the app, I really don't think I care all 
that much - but I still don't want things to crash. That's ugly.

/D


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


Re: iOS / TestFlight

2024-01-08 Thread Dirk Hohndel via subsurface
Hi Doug.

Thank you so much. The user with all the crashes reached out privately to me 
and told me that the crashes appear to happen when closing the app by swiping 
it away.
Which is much better than crashing during normal use, but still isn't what I 
want to see. So I'll investigate.

I would appreciate more testing, ESPECIALLY BLE downloads. And I happen to know 
that you went diving last weekend (your wife, Instagram -- no, I'm not ever 
spying on user data) :)

/D

> On Jan 8, 2024, at 08:45, Doug Junkins  wrote:
> 
> I have an iPhone 13 running 17.1.2 that I will try. I can upgrade to 17.2 
> after baselining with 17.1.2.
> 
> -Doug

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


Re: iOS / TestFlight

2024-01-08 Thread Dirk Hohndel via subsurface
As those on TestFlight will have seen, a new build following the new version 
number scheme was published.

I can see on TestFlight that about two dozen people have updated - I haven't 
seen any feedback whether things work / don't work. I played around with it on 
my iPad a little and didn't find anything obviously broken - but that's not the 
same as actual testing by users.

One thing that concerns me is that one user (using the anonymous link below, so 
I don't know who it is or I would reach out directly) apparently had 21 crashes 
on an iPhone 13 running iOS 17.2. And interestingly, that person appears to be 
the ONLY tester with an iPhone 13 (not Pro/Max/Mini/whatever, just 13). So I'm 
a bit concerned about there being a specific problem with that device.

If others here have a plain iPhone 13 and wouldn't mind testing, I'd appreciate 
that.

I would love to do an actual release to our complete user base fairly soon.

Thanks

/D

> On Jan 1, 2024, at 19:49, Dirk Hohndel via subsurface 
>  wrote:
> 
> 
> Finally completing the "restart all builds" project I've been on for a 
> while...
> 
> I submitted a new TestFlight build of Subsurface-mobile. As always, I have no 
> idea how long it will take to get approved and pushed out (or if they'll 
> reject it for some random reason), but the good news is that I can finally 
> build iOS phone apps again.
> 
> If you are a TestFlight tester, PLEASE TEST - especially downloading from 
> dive computers and interactions with the Subsurface Cloud.
> 
> If you aren't a TestFlight tester, have an iOS device running iOS 12 or 
> newer, and would like to help, here's the link to join the open testing:
> 
>  https://testflight.apple.com/join/k2OGhIS5
> 
> Thanks everyone - and Happy New Year!
> 

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


Re: version number changes

2024-01-06 Thread Dirk Hohndel via subsurface


> On Jan 6, 2024, at 19:26, Michael Keller  wrote:
> Thanks, this looks great now.
> I have tested local builds for android and Windows, and they work well, and 
> the version numbers are showing as expected everywhere.
> 


Thanks for testing, much appreciated.

As of about 3 minutes ago, the update check function should be working again as 
well. It's far from perfect, but it should give sensible responses in most 
scenarios :)

/D

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


version number changes

2024-01-06 Thread Dirk Hohndel via subsurface
Hi everyone,

Those who track the CICD builds may have seen a recent change... our CICD 
builds now have versions starting with 6.0.build-nr -- this change is the 
visible part of a pretty fundamental redesign how our version numbers are 
managed. I'd appreciate if people could try the various builds (I have tried 
Mac and Ubuntu already, but for example can't really try Windows). The "check 
for updates" is still broken, I'm hoping to fix that tomorrow. But the version 
in the package and report internally in the About dialog should now be 
consistent...

Thanks

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


iOS / TestFlight

2024-01-01 Thread Dirk Hohndel via subsurface

Finally completing the "restart all builds" project I've been on for a while...

I submitted a new TestFlight build of Subsurface-mobile. As always, I have no 
idea how long it will take to get approved and pushed out (or if they'll reject 
it for some random reason), but the good news is that I can finally build iOS 
phone apps again.

If you are a TestFlight tester, PLEASE TEST - especially downloading from dive 
computers and interactions with the Subsurface Cloud.

If you aren't a TestFlight tester, have an iOS device running iOS 12 or newer, 
and would like to help, here's the link to join the open testing:

 https://testflight.apple.com/join/k2OGhIS5

Thanks everyone - and Happy New Year!

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


Cloud storage changes

2023-12-28 Thread Dirk Hohndel via subsurface


Some updates on our cloud storage.

The existing cloud servers are getting older and with the significant increase 
of cloud users (now approaching twenty five thousand accounts) seemed a bit 
under-powered (which often lead to very slow response times and sometimes 
complete failure). 

Thankfully (thanks to the generosity of a handful of users - about a dozen of 
the ~25k people, or 0.05% - pretty much as expected for free resources on the 
internet, I guess) I have some funds to use for additional cloud resources. I 
took advantage of a couple of nice "year end sale" opportunities with two 
different cloud providers to add two more, significantly beefier cloud servers 
to our fleet.

As usual, I managed to get a few people caught in the transition (I think those 
are mostly straightened out by now - if you have odd issues, please reach out), 
but at this point everyone should be using the new servers.

In a moment of over-eagerness I asked myself "wouldn't it be better to have 
MORE cloud servers" - and so instead of decommissioning the old servers I have 
kept them around. And submitted a pull request that will allow us to try among 
four different servers (which continue to be kept in sync in the background - 
and in the process of debugging the migration issues, I have done some nice (I 
think) changes to the way that synchronization works).

Anyway, I hope you all are having a peaceful end of the year!

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


website updates and translation request

2023-12-28 Thread Dirk Hohndel via subsurface

Hi there,

I had some time and updated the website to reflect the current approach to 
releases.
It would be nice if someone could clean up my rough German translation and add 
translations for French, Dutch, and Portuguese (and yes, that list of languages 
is an accident of past active contributors - I am open to changing this if we 
don't have people willing to maintain the translations / new people who'd like 
to see different languages added).

The main change is to https://subsurface.github.io/download/

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


Re: new "nightly" builds available

2023-12-13 Thread Dirk Hohndel via subsurface


> On Dec 13, 2023, at 04:41, Anton Lundin  wrote:
> 
> I'd suggest you would build these builds as a different package, and
> sign them with a separate key that lives in a github actions secret.
> 
> That way one can install this nightly build in parallel with the normal
> releases, and even upgrade it between different nightly releases.
> 
> 
> This is what I've used to do, to build and run my own android builds in
> parallel with the normal released version.

Patches welcome - but yeah, I see what you are saying. Interesting idea.
Let me work on that.

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


new "nightly" builds available

2023-12-12 Thread Dirk Hohndel via subsurface
I just sent this message to the user forum. I think most of you are on there, 
but just in case...

> Begin forwarded message:
> 
> 
> The project hasn't made a release in quite a while - but a lot of people are 
> looking for more current version of the code (including newer versions of 
> libdivecomputer, for example). Over the past week I have re-enabled the 
> builds on every push/merge into the main branch of Subsurface. Fedora Copr 
> and Ubuntu Launchpad get new daily/test builds in the designated repos for 
> those OSs. Windows, macOS, and Android builds are made available as releases 
> under https://github.com/subsurface/nightly-builds/releases
> 
> The naming scheme is simple, date and a monotonic number to deal with 
> multiple builds on the same day.
> 
> Please note that none of these artifacts are signed.
> The Android APK can be side-loaded on most Android devices. If you had a 
> previous Subsurface-mobile version installed from the Google Play store, 
> you'll have to uninstall that first. And yes, this works with Android 14 
> devices and also works for new users.
> The Windows installer will ask you to confirm installation of an app from an 
> unknown developer.
> The macOS DMG makes it even harder with a multi-step dance that requires 
> opening the Privacy & Security settings in the System Preferences and 
> explicitly confirming that you are willing to install this app.
> 
> As always, the developers would love to hear about issues and concerns around 
> those builds.
> 
> /D

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


Re: "rolling" release artifacts on GitHub

2023-12-09 Thread Dirk Hohndel via subsurface


> On Dec 9, 2023, at 18:08, Michael wrote:
> 
> 
> I have used (b) in the past, and gone for a concatenation of a datestring 
> with a counter - this results in release numbers that make it obvious how 
> recent they are, which is an advantage when trying to help people reporting a 
> problem.

Yes, that is much nicer than what we do at this point.

> It also seems to be possible to create release with an indicative name 
> without having to add it as a tag in the repository - at least when using 
> GitHub actions to create the release:
> 
> 
> https://github.com/betaflight/betaflight-configurator/blob/07da3398426b5d6f1e0bd74d37f0e6f0cd622c39/.github/workflows/nightly.yml#L55

Interesting - everything I read in the documentation seemed to imply that this 
really needed a tag. How odd.

> This is how the releases created by this look like:
> 
> 
> https://github.com/betaflight/betaflight-configurator-nightlies/releases

I think that would be an excellent outcome.

Would you be willing to add this to our GitHub Actions? Or would you prefer if 
I tried my hand on this (that won't happen for a day or two - I just came back 
from Japan and have a bunch of other stuff to catch up on

> The Windows version of build 262 is working just fine in a VM running Windows 
> 10.

Thanks for testing.

> The APK version of build 262 works just fine for me on an older Xiaomi Redmi 
> Note 7 running Android 10.

Ditto

>> The app looking hung could be the initial connection / initial download from 
>> the cloud. There isn't enough visual feedback for that.
> 
> 
> This is only a problem if you have to uninstall the app and then re-install - 
> like when moving from the store app to a sideloaded version and encountering 
> a new signing key because of this. If we manage to use the same signing for 
> all of our nightly builds people will be able to upgrade between them without 
> a uninstall / reinstall, and avoid having to re-authenticate and re-download.

IIRC the builds are completely unsigned. At a minimum we'd have to create a 
release counter that's monotonic - it seems that the setup for 
betaflight-configurator already has that somewhere... I haven't looked.

>> But I'm not planning to do any UI changes until we have things working with 
>> Qt6 which will be a while.
> 
> Maybe a 'quick win' temporary fix for this would be to add a warning about 
> this to the 'Testing cloud credentials' prompt?

Sure, that seems straight forward enough


In summary:

- we need a monotonic, automatic release counter
- we should use that for all releases, regardless of platform
- we should switch to the date / counter naming scheme on all platforms
- we could add a warning to the mobile builds that there may be a fairly long 
time where the app will look dead

Am I missing anything?
Would you be willing / interested to handle any (or all 😇) of that.

Thanks

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


Re: "rolling" release artifacts on GitHub

2023-12-07 Thread Dirk Hohndel via subsurface
I should have mentioned that this only can work if you uninstall the store app.

That's a Google "feature" that actually mostly makes sense.

The app looking hung could be the initial connection / initial download from 
the cloud. There isn't enough visual feedback for that.

But I'm not planning to do any UI changes until we have things working with Qt6 
which will be a while.

For now this gives people something they can use with a current libdivecomputer 
and some other fixes.

/D

On December 8, 2023 12:01:56 PM GMT+09:00, Mark Stiebel  wrote:
>
>I downloaded 261 (and 262) and both of them presented the invalid package 
>error.  But after uninstalling the Google Play store version the APK installed 
>successfully. I'm running 262 at the moment.  The first time running, after 
>entering my credentials I was presented with an empty dive list. I tried to go 
>to the menu and force a cloud sync, but the app just hung with the menu panel 
>open. I killed it and restarted, and after a not much more than a cursory 
>glance things seems to be working OK.
>
>> 
>>> 
>>>  I still can't adb to actually work here on the mac that I'm traveling with 
>>> - so I remotely installed the apk on a device connected at home for that 
>>> purpose. adb seemed to think it installed correctly - but maybe it failed 
>>> and I just can't see it?
>> 
>> I solved my adb problem, identified the problem with the APK, and there's 
>> now a new 5.0.10.261.apk that appears to work here -- admittedly very 
>> limited testing so far.
>> 
>> /D
>> 

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


Re: "rolling" release artifacts on GitHub

2023-12-07 Thread Dirk Hohndel via subsurface



> On Dec 8, 2023, at 07:56, I wrote:
> 
> 
> I still can't adb to actually work here on the mac that I'm traveling with - 
> so I remotely installed the apk on a device connected at home for that 
> purpose. adb seemed to think it installed correctly - but maybe it failed and 
> I just can't see it?

I solved my adb problem, identified the problem with the APK, and there's now a 
new 5.0.10.261.apk that appears to work here -- admittedly very limited testing 
so far.

/D

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


Re: "rolling" release artifacts on GitHub

2023-12-07 Thread Dirk Hohndel via subsurface
well, two reports clearly state a trend.
back to the drawing board.

I still can't adb to actually work here on the mac that I'm traveling with - so 
I remotely installed the apk on a device connected at home for that purpose. 
adb seemed to think it installed correctly - but maybe it failed and I just 
can't see it?

Hrmpf

/D

> On Dec 8, 2023, at 07:39, Mark Stiebel  wrote:
> 
> 
> Same story here. Just tried to install Subsurface-mobile-5.0.10.260.apk 
> <https://github.com/subsurface/subsurface/releases/download/latest/Subsurface-mobile-5.0.10.260.apk>
>  on my Motorola Thinkphone (Android 13) with and "invalid package" error.
>  
> <https://github.com/subsurface/subsurface/releases/download/latest/Subsurface-mobile-5.0.10.260.apk>
>> I have tried installing the APK in my S20, but it fails as it appears to be 
>> an invalid package :(
>> Not sure if that's an issue locally, or a general one (I've been fighting 
>> with the Blackberry "business restriction" nonsense since we started using 
>> it to control access to work systems).
>> 
>> On 7 Dec 2023, at 19:22, Dirk Hohndel via subsurface 
>> > <mailto:subsurface@subsurface-divelog.org>> wrote:
>>> 
>>> And I'd love to know how the Android APK works for people trying to 
>>> side-load Subsurface-mobile onto an Android device.
>>> In one quick test for me it seemed to be fine (if awkward and annoying) - 
>>> but I'd love to make sure a few more people with non-Google devices try 
>>> this (for reasons of personal preferences I only tend to use plain Google 
>>> Android devices... therefore I'd love to make sure that this works with 
>>> Samsung or  devices as well.
>>> 
>>> /listinfo/subsurface 
>>> <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


"rolling" release artifacts on GitHub

2023-12-07 Thread Dirk Hohndel via subsurface

As Michael and I try to improve the way we post binaries for people to test and 
use, following up on the Ubuntu and Fedora binaries I mentioned earlier, we now 
have binaries posted on GitHub as "daily" or "latest" releases: 
https://github.com/subsurface/subsurface/releases/tag/latest

There is an oddity about the way this works. GitHub only does releases for 
tags. So there are basically two options:
(a) do a "latest" tag and post all the binaries under that (which is what I've 
done so far)
(b) create a tag for every merge / push to the master branch

Both have drawbacks:
(a) creates a real mess with quickly having many, many artifacts in that same 
'latest' release and the user having to figure out which ones to download.
(b) creates a real mess as the git repo gets flooded with new tags - but then 
the releases themselves look much more sane

I'm curious what people think would be the better strategy - or if there's a 
third option that I've missed.

I'd also appreciate if people could try these new and improved Windows builds 
(they use a fresh build container with the very latest Qt5.15 libraries, newer 
compiler, and several other newer dependencies compared to those that I posted 
last week. I'd be especially interested if there are any improvements to BT / 
BLE handling, as there were numerous updates to the corresponding code in Qt.

And I'd love to know how the Android APK works for people trying to side-load 
Subsurface-mobile onto an Android device.
In one quick test for me it seemed to be fine (if awkward and annoying) - but 
I'd love to make sure a few more people with non-Google devices try this (for 
reasons of personal preferences I only tend to use plain Google Android 
devices... therefore I'd love to make sure that this works with Samsung or 
 devices as well.

Thanks

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


Re: trying to build CD releases from GitHub

2023-12-05 Thread Dirk Hohndel via subsurface



> On Dec 6, 2023, at 08:07, Matt Thompson via subsurface 
>  wrote:
> 
> The binary installs and is basically functional.  I was not able to download 
> dives from my Perdix AI.  The dive computer is found when I scan for devices 
> in Subsurface, but the connection fails.  I don't know if that is a 
> temperamental Perdix or something with the binary.  
> 
> Keyboard navigation, maps, preferences, dive profile options, all seem to 
> work fine for me.

Thank you so much for the quick test and immediate feedback. That's awesome - 
so at least I didn't break anything.

Now the next step is to update all of this to more current versions of the 
dependencies and make sure that those are working well.

Please stay tuned for more :)

/D

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


trying to build CD releases from GitHub

2023-12-05 Thread Dirk Hohndel via subsurface

I appear to be making progress in setting this up.

We now have working "daily" releases again pushed to Launchpad (for Ubuntu, 
Debian, etc) and Copr (for Fedora)
And just now I have a first successful test run of creating Windows builds as 
well.

But as I'm traveling, I have no access to a Windows system and can't test 
those. If one of you has such access and has a moment - I'd appreciate a quick 
sanity check:

 https://github.com/subsurface/subsurface/releases/tag/latest

Thanks

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


Re: web server moved

2023-12-02 Thread Dirk Hohndel via subsurface
Sorry for the top post... I'm about to head to the airport and the computer is 
already packed.

I'd suggest migration to the GitHub.io setup we already have for about half of 
the pages. That means we don't have to maintain the website itself, just the 
content...

/D

On December 2, 2023 2:01:34 PM PST, Robert Helling  wrote:
>Hi Dirk and all,
>
>> On 30. Nov 2023, at 19:45, Dirk Hohndel via subsurface 
>>  wrote:
>> 
>> The bad news is that both the slider with the pictures on the home page as 
>> well as the drop down menu for narrow screens (so the hamburger in the top 
>> left) had already been broken before - it's just that no one noticed. And 
>> given that I hadn't touched the website in quite a while, I have to assume 
>> that it had been broken for a while.
>> 
>> I'm not sure where to take this from here. The logical next step really is 
>> to just recreate the home page on the GitHub.io <http://github.io/> page and 
>> be done with having our own web server - except for the update check and the 
>> actual download / hosting of the binaries, I guess.
>> 
>> Of course that once again is something that will require time and effort.
>> 
>> If any of you are familiar with the GitHub.io <http://github.io/> website 
>> system and want to contribute to Subsurface - here's your chance…?
>
>in my hybris, I have just tried to understand why the hamburger menu button is 
>broken. But even with my browser in developer mode and page sources etc I 
>failed (to be expected since I know almost nothing about java script). It 
>seems that the magic that swaps the left hand side navigation bar for the 
>hamburger menu once the window gets too narrow has been put there by Wordpress 
>which in turn seems to use the divi library which you are supposed to use via 
>a GUI to compose your java script (which is then minimised because who needs 
>speaking variable names?). It’s all a total mess.
>
>You are probably right (as always): If updating Wordpress to a recent version 
>to produce new static pages is not an option, it seems we will have to start 
>from scratch. Do you have any idea how we can transfer the old content (with 
>different languages etc)?
>
>Best
>Robert
>
>

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


Re: web server moved

2023-11-30 Thread Dirk Hohndel via subsurface
Well, 

There's good news, and there is bad news.
The good news is that I didn't break things.
The bad news is that both the slider with the pictures on the home page as well 
as the drop down menu for narrow screens (so the hamburger in the top left) had 
already been broken before - it's just that no one noticed. And given that I 
hadn't touched the website in quite a while, I have to assume that it had been 
broken for a while.

I'm not sure where to take this from here. The logical next step really is to 
just recreate the home page on the GitHub.io page and be done with having our 
own web server - except for the update check and the actual download / hosting 
of the binaries, I guess.

Of course that once again is something that will require time and effort.

If any of you are familiar with the GitHub.io website system and want to 
contribute to Subsurface - here's your chance...?

/D

> On Nov 29, 2023, at 22:31, Dirk Hohndel via subsurface 
>  wrote:
> 
> Not sure about the pictures, I'll have to try to reproduce this here. In my 
> limited testing I didn't notice that.
> 
> And yes, a good chunk of our website has been reported to the GitHub.io site 
> because that made it so much easier to maintain.
> 
> Are any of these links wrong?
> 
> (The website hasn't been a WordPress site in many years and is all static 
> files, so I can't even imagine how the links would have changed)
> 
> 
> /D

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


Re: Fwd: web server moved

2023-11-29 Thread Dirk Hohndel via subsurface
Ironically, my email was to the developer mailing list and not to the user 
forum / Google group...

But yes, I can reproduce the menu not working. I'm curious if I broke this in 
the migration or if this was broken before. I haven't tried the website on 
Mobile in a while.

Thanks

/D

On November 29, 2023 8:50:56 PM PST, Benjamin  wrote:
>And of course, posting first thing in the morning, before coffee, means
>that I'm not mentally able to post to the group, and instead posted
>directly to Dirk. Resending to everyone.
>
>Benjamin
>
>-- Forwarded message -
>From: Benjamin 
>Date: Thu, 30 Nov 2023, 06:49
>Subject: Re: web server moved
>To: Dirk Hohndel 
>
>
>Good morning. The only thing I saw during a quick and shallow test browse -
>which could also just be my cellphone acting up - was that the menu didn't
>work from the homepage. I'll recheck from a computer as soon as I am able
>to do so.
>
>Benjamin
>
>On Thu, 30 Nov 2023, 00:48 Dirk Hohndel via subsurface, <
>subsurface@subsurface-divelog.org> wrote:
>
>>
>> Another quick note from over here
>>
>> I have finally moved the web server / update check server to a static IP
>> address.
>> As a result either all problems are solved, or I have broken stuff
>> catastrophically.
>>
>> I know which one my money is on.
>>
>> I'd appreciate some gentle testing of this and feedback in case you
>> stumble across something odd.
>>
>> /D
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>
>-- 
>You received this message because you are subscribed to the Google Groups 
>"Subsurface Divelog" group.
>To unsubscribe from this group and stop receiving emails from it, send an 
>email to subsurface-divelog+unsubscr...@googlegroups.com.
>To view this discussion on the web visit 
>https://groups.google.com/d/msgid/subsurface-divelog/CANwt24Lxde9xKbkGQqTg6VYe2PqmrpUxnX%2Beh4EY7iKjH72-ng%40mail.gmail.com.

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


Re: web server moved

2023-11-29 Thread Dirk Hohndel via subsurface
Not sure about the pictures, I'll have to try to reproduce this here. In my 
limited testing I didn't notice that.

And yes, a good chunk of our website has been reported to the GitHub.io site 
because that made it so much easier to maintain.

Are any of these links wrong?

(The website hasn't been a WordPress site in many years and is all static 
files, so I can't even imagine how the links would have changed)


/D

On November 29, 2023 10:06:03 PM PST, Miika Turkia  
wrote:
>For some reason, I seem to be missing a picture on the front page. If I
>right-click on the empty space and open image to new tab, it loads the
>image fine. When viewing translated pages, those are missing all the
>pictures in the front page.
>[image: image.png]
>
>Many links seem to point to https://subsurface.github.io/, not sure how
>this was supposed to be.
>
>This is what I noticed in a quick check.
>
>miika

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


web server moved

2023-11-29 Thread Dirk Hohndel via subsurface


Another quick note from over here

I have finally moved the web server / update check server to a static IP 
address.
As a result either all problems are solved, or I have broken stuff 
catastrophically.

I know which one my money is on.

I'd appreciate some gentle testing of this and feedback in case you stumble 
across something odd.

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


Qt6 and Android

2023-11-29 Thread Dirk Hohndel via subsurface


Hi everyone,

just a quick note that I'm still around (mostly dealing with the backend / 
cloud storage these days) and haven't forgotten about Android.
Recap of those of you who have (forgotten, that is)...

- QtBluetooth from Qt 5.15.x seems incapable of complying with last year's 
changes to the Google Play permission rules for BLE access
- build using Qt 5.15.x have been rejected for more than half a year because 
they are in violation of said rules
- I have been trying on and off to get things to build with Qt6 (which 
allegedly can comply), but that fails because Kirigami hadn't been ported to Qt6

As of a couple of weeks ago the KDE / PLASMA-mobile community has a pre-alpha 
version of Kirigami running against the Qt 6.6 prerelease that appears to show 
some signs of life on Android. So I have started to figure out how to build 
against that which is (to put it mildly) a fascinating learning experience.

But at least in theory there's now a chance that we have a path forward to once 
again providing an updated Android app.

Of course - and let's not forget to mention the elephant in the room - I don't 
think anyone is actively working on the mobile app in the first place anymore. 
Nor do I understand how all this would work on iOS since the KDE community 
quite specifically isn't targeting iOS.

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


Re: Subsurface-mobile support request / Lost Logs when synced to cloud

2023-10-16 Thread Dirk Hohndel via subsurface
I'm glad I was able to help 

All the best

/D

On October 16, 2023 10:18:00 PM EDT, Callie K  wrote:
>Hi Dirk,
>
>Wow! You are amazing… Thank you so much.
>
>I am sorry I have inconvenienced you with this problem, and express my deepest 
>appreciation and gratitude for helping me. That is extremely kind and generous 
>of you.
>
>Thank you for telling me how to avoid this issue again.
>
>I would like to make a contribution or a donation if there is a PayPal or 
>Venmo name, or a credit card app that I could contribute to. Please let me 
>know.
>
>Thank you, and all your associates for your devotion, care and great work.
>
>Respectfully,
>Callie
>
>
>
>On Oct 15, 2023, at 10:47 PM, Dirk Hohndel  wrote:
>
> Hi Callie,
>
>It took about a solid hour of work, but I believe I have restored all of the 
>deleted dives in your cloud account.
>
>Please refresh (ideally on all of your devices/computers) the cloud storage 
>account to make sure everything is where you want it to be.
>I may have lost a dive site or two in the process (if I did, then it's for 
>dives on Oct 7 and 8), but I think everything else should be back to normal.
>
>And to reiterate what I wrote before, to ensure that you don't get into this 
>situation again, please ensure that you ALWAYS manually sync with the cloud 
>storage before editing dives or downloading dives from a dive computer.
>
>Sorry for the inconvenience.
>
>/D
>
>On Oct 15, 2023, at 17:23, Callie K wrote:
>
>Hello Dirk,
>
>Thank you for your email.
>
>First of all, I would like to thank you for the product/service and now 
>understand this is a hobby for a bunch of people. A great hobby!
>
>I’m sorry if my message came across as if there is a misunderstanding as to 
>what is happening. There was no anger outbursts directed towards the 
>developers, nor anger channeled in any direction whatsoever. Frustration with 
>the failure or under development, of what I now understand happened, yes. I 
>always recognize that there are bugs, issues, and unknowns that surface 
>continually and throughout our evolution of IT advancement. I am a solution 
>driven individual who understands things happen and always try to find 
>solutions, and then preventative measures. May be a better way for me to use 
>Subsurface.
>
>I think what I take from this, and your dramatic email, is that, a couple 
>websites so highly recommend your product/service without sharing, or me 
>recognizing, it is not a business level system. Also, lost data occurrences 
>frequently do happen with users, and there may be some under development 
>issues, and that’s okay. After this happened to me, I did Google everything 
>looking for a solution and found that it has a pattern that occurs more 
>frequently.
>
>I relied on it perhaps more than I was aware that I should have. And I have no 
>problem using a paid service, because, this information is rather important in 
>its’ nature for what I am using it for.
>
>As I said earlier here, I did Google the issue. I do have a Google account, 
>and in excellent standing. I am an upstanding citizen. My reference of “not 
>allow me in” was due to the fact that I was “not a member“ of the group. I had 
>a difficult time and ultimately, not able to learn how to either request, or 
>add this group to my Google account, for access. When I followed the links to 
>all the similar problems I found, they led to the Google Account. Again, it 
>allowed me to only read maybe the first few sentences or post. It would not 
>allow me to see the additional comments, and understand it further. Either 
>from my lack of experience with the Subsurface set up, or not being able to 
>identify how to or, what the name of the group was, to add to my Google 
>account.
>
>I was unaware that I was using a developer emailing list. I came across an 
>email that appeared to be a support email. I am not interested in having 
>developer access.
>
>I’m sorry if my description came across garbled and confusing. I opened up 
>Subsurface app on my computer to enter some logs. I noticed one of the logs 
>and edited the name. If I recall correctly, I saved it to the cloud, and then 
>I noticed I was missing a few dive logs. So then I entered a “test dive“ to 
>see if there was a server updating concern. Upon entering it, I saved it to 
>the cloud on my computer, and then it deleted all the other logs, and had just 
>that one “test log”. As I said, in the other email, I know for sure I did not 
>delete any dive logs.
>
>I believe I closed out the computer and opened my iPhone, and saw that the 
>three or four were still missing the few dives, but had all the others there. 
>So I synced it to the cloud, and then it deleted the rest of them, and only 
>left me with the “test’ dive”.
>
>Yes, I would appreciate your help in restoring them and am giving explicit 
>permission to help me in any way that you can. I understand this is a hobby, 
>and would be okay if I had to just write it off and re-create it again, or 
>even 

Re: Subsurface-mobile support request / Lost Logs when synced to cloud

2023-10-15 Thread Dirk Hohndel via subsurface
Hi Callie,

It took about a solid hour of work, but I believe I have restored all of the 
deleted dives in your cloud account.

Please refresh (ideally on all of your devices/computers) the cloud storage 
account to make sure everything is where you want it to be.
I may have lost a dive site or two in the process (if I did, then it's for 
dives on Oct 7 and 8), but I think everything else should be back to normal.

And to reiterate what I wrote before, to ensure that you don't get into this 
situation again, please ensure that you ALWAYS manually sync with the cloud 
storage before editing dives or downloading dives from a dive computer.

Sorry for the inconvenience.

/D

> On Oct 15, 2023, at 17:23, Callie K wrote:
> 
> Hello Dirk,
> 
> Thank you for your email.
> 
> First of all, I would like to thank you for the product/service and now 
> understand this is a hobby for a bunch of people. A great hobby!
> 
> I’m sorry if my message came across as if there is a misunderstanding as to 
> what is happening. There was no anger outbursts directed towards the 
> developers, nor anger channeled in any direction whatsoever. Frustration with 
> the failure or under development, of what I now understand happened, yes. I 
> always recognize that there are bugs, issues, and unknowns that surface 
> continually and throughout our evolution of IT advancement. I am a solution 
> driven individual who understands things happen and always try to find 
> solutions, and then preventative measures. May be a better way for me to use 
> Subsurface.
> 
> I think what I take from this, and your dramatic email, is that, a couple 
> websites so highly recommend your product/service without sharing, or me 
> recognizing, it is not a business level system. Also, lost data occurrences 
> frequently do happen with users, and there may be some under development 
> issues, and that’s okay. After this happened to me, I did Google everything 
> looking for a solution and found that it has a pattern that occurs more 
> frequently.
> 
> I relied on it perhaps more than I was aware that I should have. And I have 
> no problem using a paid service, because, this information is rather 
> important in its’ nature for what I am using it for.
> 
> As I said earlier here, I did Google the issue. I do have a Google account, 
> and in excellent standing. I am an upstanding citizen. My reference of “not 
> allow me in” was due to the fact that I was “not a member“ of the group. I 
> had a difficult time and ultimately, not able to learn how to either request, 
> or add this group to my Google account, for access. When I followed the links 
> to all the similar problems I found, they led to the Google Account. Again, 
> it allowed me to only read maybe the first few sentences or post. It would 
> not allow me to see the additional comments, and understand it further. 
> Either from my lack of experience with the Subsurface set up, or not being 
> able to identify how to or, what the name of the group was, to add to my 
> Google account. 
> 
> I was unaware that I was using a developer emailing list. I came across an 
> email that appeared to be a support email. I am not interested in having 
> developer access. 
> 
> I’m sorry if my description came across garbled and confusing. I opened up 
> Subsurface app on my computer to enter some logs. I noticed one of the logs 
> and edited the name. If I recall correctly, I saved it to the cloud, and then 
> I noticed I was missing a few dive logs. So then I entered a “test dive“ to 
> see if there was a server updating concern. Upon entering it, I saved it to 
> the cloud on my computer, and then it deleted all the other logs, and had 
> just that one “test log”. As I said, in the other email, I know for sure I 
> did not delete any dive logs. 
> 
> I believe I closed out the computer and opened my iPhone, and saw that the 
> three or four were still missing the few dives, but had all the others there. 
> So I synced it to the cloud, and then it deleted the rest of them, and only 
> left me with the “test’ dive”.
> 
> Yes, I would appreciate your help in restoring them and am giving explicit 
> permission to help me in any way that you can. I understand this is a hobby, 
> and would be okay if I had to just write it off and re-create it again, or 
> even not use Subsurface, as my backup from herein. Understandably, I would 
> like to know how to make sure I don’t create this scenario again.
> 
> Thank you so much for taking the time to write here. I think you have a great 
> product/service and I’m excited to see you continue to grow and evolve! Kudos 
> to all of you with your work and achievements with Subsurface. 
> 
> Thank you Dirk. 
> 
> Respectfully,
> Callie
> 
> 
> 
>> On Oct 15, 2023, at 12:53 PM, Dirk Hohndel  wrote:
>> 
>> 
>> The tone of your message makes me think that you are misunderstanding what 
>> is happening.
>> 
>> (a) the Google group requires a Google account. But it shouldn't (and 

Re: Subsurface-mobile support request / Lost Logs when synced to cloud

2023-10-15 Thread Dirk Hohndel via subsurface
The tone of your message makes me think that you are misunderstanding what is 
happening.

(a) the Google group requires a Google account. But it shouldn't (and to the 
best of my knowledge doesn't) reject anyone who hasn't been banned from other 
groups for excessive abusive behavior in the past.
(b) the developer mailing list that you tried sending an email to has been 
overrun with subscription spam and now requires explicit approval from me to 
add people - but I don't think that you want to be a developer from the way 
this all sounds
(c) your description of what happens is garbled and confusing. Please try to 
explain in sequence what happened, how many devices / computers were involved, 
etc
(d) any data that was at some point saved to the cloud (so that has 
successfully synced between two or more devices) is still there. You just 
managed to confuse the algorithm with the sequence of actions which resulted in 
it assuming that you wanted to replace old dives with new ones, instead of 
adding new ones.

I'll repeat what I have said in dozens of answers that your search found 
already. This is an open source project - a hobby for a bunch of people. Angry 
outbursts at the developers might work for a paid product (newsflash, they 
usually don't), but when attacking someone who wants to help you because it's 
something that they like to do, it generally tends to have the opposite effect.

If you would like help, I need two things
(a) your explicit permission to access your cloud data (because I never 
interact with user dive data without such explicit permission)
(b) a good descriptions of which dives should be there (how many, what rough 
time frame are they from) and the sequence of events that made everything 
disappear - because I need to undo those events in the backend, and the more 
information I have on what happened, the easier that process will be.

Finally, as to your question how to avoid this in the future - in about half of 
the cases the issues is that on a PC you downloaded new dives before opening 
the cloud storage and then ended up overwriting cloud storage. The other half 
are situation where you made changes on two different devices without syncing 
first. There are a couple of other scenarios, but they are very rare. The 
simple approach to preventing this issue is to simply always sync with the 
cloud FIRST, before making any changes (downloading new dives from a dive 
computer, editing dives, etc).

/D

> On Oct 14, 2023, at 21:04, Callie K  wrote:
> 
> Hello,
> 
> I am very upset. All my data was lost from your app tonight.
> 
> I edited one dive log, sync’d to the cloud, and it deleted four of them. 
> Shortly there after, I wasn’t sure what happened and I added another dive log 
> and sync’d it to the cloud again. This time I deleted all the remainder of my 
> logs. There were about 40 dive logs.
> 
> There is no way I deleted my dove log information, just no way.
> 
> I googled this issue and saw numerous other posts about this problem. I even 
> went over to your Google groups, but it would not allow me in, please explain 
> how to access, that Google sector/forum. I wasn’t able to find any way to add 
> that as a group, nor register.
> 
> Please restore the data, your app deleted, hid, or re-distributed to another 
> area.
> 
> Also, please explain what caused this problem so as it can be avoided in the 
> future.
> 
> Thank you,
> Callie
> 
> 
> Please describe your issue here and keep the attached logs.
> 
> 
> 
> 
> 
"0.000: Successfully opened logfile 
/var/mobile/Containers/Data/Application/C61B6173-EAEC-4239-95F3-9A3E5FAE8B5F/Documents/subsurface.log
 at Sat Oct 14 22:22:14 2023"
"0.000: Starting Subsurface-mobile:3.4.7(5.0.9.33):iOS 16.6:arm64:en-US"
"0.000: built with libdivecomputer v0.8.0-devel-Subsurface-NG 
(a17e466bd1d2e675666e20862182d618cf6d7190)"
"0.000: built with Qt Version 5.15.2, runtime from Qt Version 5.15.2"
"0.000: built with libgit2 1.0.1"
"0.000: Running on iOS 16.6"
discovery methods 2
starting BT/BLE discovery
QObject::connect(QUndoStack, QMLManager): invalid nullptr parameter
"0.015: download page -- looking for known BT/BLE device"
"0.018: [screensetup] width changed now 510 x 765 vs screen 428 x 926"
"0.018: [screensetup] window width changed to 510 orientation 1"
"0.018: [screensetup] remembering new orientation"
qrc:/qml/StatisticsPage.qml:142:4: QML TemplateSlimComboBox: Binding loop 
detected for property "currentIndex"
qrc:/qml/StatisticsPage.qml:125:4: QML TemplateSlimComboBox: Binding loop 
detected for property "currentIndex"
qrc:/qml/StatisticsPage.qml:108:4: QML TemplateSlimComboBox: Binding loop 
detected for property "currentIndex"
"0.038: StartPage visibility changed to false"
"0.038: not yet initialized, show busy spinner"
"0.039: regular font size changed to 16"
qrc:/qml/DiveSummary.qml:33:2: QML Connections: Implicitly defined onFoo 
properties in Connections are deprecated. Use this syntax instead: function 
onFoo() { ... }

Re: Can't access cloud storage from PcWindows Application

2023-10-01 Thread Dirk Hohndel via subsurface
Can you create a log file for this?
So quit the app, start the app again, connect to the cloud (have it fail), quit 
the app again, and then send us the log files in
C:\Users\Home\AppData\Roaming\Subsurface: there you should see the two files 
subsurface_out.log and subsurface_err.log

Thanks

/D

> On Oct 1, 2023, at 04:46, Emanuela Alfieri via subsurface 
>  wrote:
> 
> Hi,
> 
> As per the subject, when I try to connect to the cloud from the Windows app 
> (32 bit), the message is always incorrect password.
> 
> I can access from my Android phone and the web platform.
> 
> I also reset my password, but nothing changes
> 
> Thanks in advance
> ___
> 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: Hacktoberfest

2023-09-06 Thread Dirk Hohndel via subsurface
I have been struggling to find the energy to do the "maintainer" part of the 
work for a while now.
Most of my Subsurface time is spent on dealing with the infrastructure and 
helping people with cloud issues...

So from my perspective... I'm not against it, but I can't commit resources to 
dealing with the PRs...

/D

> On Sep 6, 2023, at 18:22, Michael Keller via subsurface 
>  wrote:
> 
> Hi Dirk, Linus, et. al.
> 
> What are thoughts around allowing contributions to Subsurface to be counted 
> towards this year's Hacktoberfest?
> 
> I have done this with other open source projects in past years, and found 
> that this is normally quite good at motivating people to contribute during 
> the month.
> 
> The caveat is that this year there will be no more free tshirts or other 
> physical goodies sent out to participants with a sufficient number of 
> contributions during the month - we'll see what impact this will have.
> 
> There might be the odd low value pull request coming out of it, but even 'low 
> value' (like fixing a few typos in the documentation) is better than no value.
> 
> The instructions for participation for maintainers are here: 
> https://hacktoberfest.com/participation/#maintainers
> Basically we already tick almost all of the boxes, all we need is to add the 
> 'hacktoberfest' topic to the repositories we want to allow participating pull 
> requests for.
> 
> Ngā mihi
>   Michael Keller
> -- 
> GCS$/CC/E/IT d- s+ a C++ UL+++/S++ P L++ E-
> W++ N o? K? w O(++) M-- V+ PS+ PE+ Y? PGP+ t
> 5? X R tv b++ DI++ D++ G e+++ h r+++ y+++
> ___
> 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: lost dive log entries

2023-08-25 Thread Dirk Hohndel via subsurface
Send me email FROM the address that you use for your cloud storage, and give me 
explicit permission to access your data in the cloud.
All old dives should still be in the repo and I can usually restore them fairly 
easily.

/D

> On Aug 25, 2023, at 15:41, Matt Wilbur  wrote:
> 
> Hello
> 
> I am not sure what happened - I d/l my logs to my mobile subsurface app, and 
> then do a sync to the cloud to store them in the cloud. Then later on my mac 
> I open subsurface, sync, and have my logs in both places.
> 
> Today I did the first half of that -- got todays dive downloaded, looked ok. 
> did a manual sync, and on my mac when i synced with the cloud, it looks like 
> it dropped about 30 dives, and the most recent dive showed as dive #0. I 
> don't know where dives 526 to 553 went.  I went back to my mobile app, which 
> still "looked" good - had 553 or whatever. And then like an idiot, I told it 
> to a sync and it pulled down whatever happened on the mac subsurface and now 
> its lost my dives as well.
> 
> Does subsurface do any periodic backups?  Do we just mark deleted dives as 
> deleted in the DB and they may still be recoverable? I'm sure i fat fingered 
> something- but I recently sold one of my dive comps and may not be able to 
> get the data from some of the dives loaded back in :(
> 
> help!

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


Re: iOS Test build 5.0.10.212

2023-08-16 Thread Dirk Hohndel via subsurface
I'm confused... you are running the iOS version on a Mac? Or did you mean the 
macOS version?

/D

> On Aug 16, 2023, at 13:49, MAX  wrote:
> 
> I downloaded iOS test build 5.0.10.212. To give it a spin and to see if it 
> would allow me to download dives from my deep6 excursion with their new “Tech 
> lite” software. It’s my understanding that it is supported in 
> libdivecomputer.  When I tried to down load the dives I could get my Mac to 
> see the dive computer and establish a Bluetooth connection but then got a 
> message there were no dives to download. I am not a developer but if I can 
> help with any more info I’m happy to provide it but will probably need some 
> instructions if you need log files or the like 
> 
> Thanks for all you do 
> ___
> 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: we need to make a new release

2023-08-16 Thread Dirk Hohndel via subsurface



> On Aug 16, 2023, at 09:34, Berthold Stoeger  
> wrote:
> On Mittwoch, 16. August 2023 18:10:36 CEST Robert.Helling wrote:
>> fine with me. I should say, however, I am on summer vacation with the family
>> and only have my new M2 based Macbook Pro with me on which I cannot build
>> Subsurface as of now (see my earlier mail) as the linker complains missing
>> intel symbols from the libraries. Any suggestions appreciated.

I need to find that thread... I just completed another build on my M1 MBP and 
it seems
just fine... I will do a clean build from scratch on a different system in a 
little while, so
let's see if I can reproduce your issues

> Similar situation for me: Fine with me, but on Friday I'll leave for a 
> conference in Australia until September 1st and will only have time very 
> sporadically.

Australia. NICE. Love that place.

Are there any open issues concerns from your side, or are the sources as they 
are
pretty good as far as your code goes?

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


we need to make a new release

2023-08-16 Thread Dirk Hohndel via subsurface


Michael, Berthold, Robert,

what are your thoughts about stabilizing the current state and releasing a 5.1 ?

It's been way too long since we published an official release. I should have 
some time the next couple of weeks to ensure we have good builds, etc.

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


Re: Android APP

2023-06-01 Thread Dirk Hohndel via subsurface
You are using the beta version which is currently broken.
There are some rather frustrating interdependencies that make it extremely hard 
to rebuild the app and follow the new requirements of the Google Play store - 
so this will stay broken for a while, I'm afraid.

The simple work around is to leave the beta program and go back to the 
production app.

/D

> On Jun 1, 2023, at 05:59, Leo Ekelmans via subsurface 
>  wrote:
> 
> Dear Subsurface developpers,
> 
> I am a happy user of the subsurface programs on Android, ipad and mac book.
> Unfortunately since the latest Android update of May 27th the app is crashing 
> on my Samsung A52. Not sure if this has been reported sofar
> 
> Regards,
> Leo
> ___
> 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: mobile apps

2023-05-29 Thread Dirk Hohndel via subsurface
You can leave the beta and get the release version back. I'm trying to replace 
the broken build, but right now things aren't going my way...

/D

On May 29, 2023 6:48:01 AM PDT, Adolph Weidanz via subsurface 
 wrote:
>No worries, I have it installed on my desktop and that works fine.
>
>On Sun, May 28, 2023 at 8:20 PM Dirk Hohndel  wrote:
>>
>> I'm about five hours into trying to get to a working build environment that 
>> complies with what the play store now requires.
>> To say that this is a somewhat frustrating exercise would be greatly 
>> understate my feelings on this matter...
>>
>> So, err, yeah... don't bother testing the current Android beta :(
>>
>> /D
>>
>> > On May 28, 2023, at 4:28 PM, Adolph Weidanz via subsurface 
>> >  wrote:
>> >
>> > I downloaded 3.4.8 (5.0.10.377) on my samsung Note 20, running Android
>> > 13 kernel 4.19.113-26203352.
>> >
>> > Soon as I started it up it crashed, Tried again and android says to
>> > clear the cache and try again. Did so with no change. Gets to the
>> > white screen and then dies.
>> >
>> > On Sun, May 28, 2023 at 5:58 PM Mark Stiebel via subsurface
>> >  wrote:
>> >>
>> >> If I try and launch from my home screen or the app drawer on my OnePlus 8 
>> >> Pro I get "Permission Denied".
>> >>
>> >> From App Info > Open, it shows the splash screen momentarily and then 
>> >> shuts down. I've checked app permissions, and it has access to everything 
>> >> it's asking for (Location, Notifications, Photos & Videos, Music & Audio).
>> >>
>> >> It didn't have access to photos and video or music and audio previously 
>> >> (not sure why it's asking for audio?) but I added just to be sure.
>> >>
>> >> Mark.
>> >> ___
>> >> 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
>>
>___
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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


Re: mobile apps

2023-05-28 Thread Dirk Hohndel via subsurface
Thank you so much for the detailed test report.
After all the frustration with the Android build today, this is some welcome 
good news!

/D

On May 28, 2023 8:14:05 PM PDT, Hartley Horwitz via subsurface 
 wrote:
>On iphone 13 mini running iOS 16.5, I downloaded 5.0.10.177.   I tried the
>following features with nothing to report
>* no issues with install
>* no issues downloading/uploading to cloud
>* switched to a different user
>* edited a dive
>* filtered dives with different tags
>* scrolled through various submenus of the main subsurface menu
>* scrolled through dive list using top buttons, or left/right swipes
>* changed 2 settings (units, colors)
>* selected location button on a dive to view map, zoomed in/out
>* landscape mode to look at just the graph, zoomed in/out
>* toggled ceiling on/off
>
>Features still to try (another day)
>* download from dive computer(s)
>* deleting dive
>
>Looks like a good iOS release.
>
>...Hartley Horwitz
>
>>
>>

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


Re: mobile apps

2023-05-28 Thread Dirk Hohndel via subsurface
I'm about five hours into trying to get to a working build environment that 
complies with what the play store now requires.
To say that this is a somewhat frustrating exercise would be greatly understate 
my feelings on this matter...

So, err, yeah... don't bother testing the current Android beta :(

/D

> On May 28, 2023, at 4:28 PM, Adolph Weidanz via subsurface 
>  wrote:
> 
> I downloaded 3.4.8 (5.0.10.377) on my samsung Note 20, running Android
> 13 kernel 4.19.113-26203352.
> 
> Soon as I started it up it crashed, Tried again and android says to
> clear the cache and try again. Did so with no change. Gets to the
> white screen and then dies.
> 
> On Sun, May 28, 2023 at 5:58 PM Mark Stiebel via subsurface
>  wrote:
>> 
>> If I try and launch from my home screen or the app drawer on my OnePlus 8 
>> Pro I get "Permission Denied".
>> 
>> From App Info > Open, it shows the splash screen momentarily and then shuts 
>> down. I've checked app permissions, and it has access to everything it's 
>> asking for (Location, Notifications, Photos & Videos, Music & Audio).
>> 
>> It didn't have access to photos and video or music and audio previously (not 
>> sure why it's asking for audio?) but I added just to be sure.
>> 
>> Mark.
>> ___
>> 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

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


Re: mobile apps

2023-05-28 Thread Dirk Hohndel via subsurface


> On May 28, 2023, at 14:46, Michael Andreen  wrote:
> 
> On Sunday 28 May 2023 23:16:26 CEST Dirk Hohndel via subsurface wrote:
> > The apps are now both available for beta testers.
> >
> > Something in the required changes to make it past the Google Play rule 
> > changes apparently completely broke the Android app - it doesn't even start.
> > Needless to say, the local install prior to those enforced changes actually 
> > worked - so now I need to debug what went wrong there.
> > Ugh.
> 
> Was just about to send my report when I noticed that this showed up. Here is 
> some additional information:
> 
> On my OnePlus 8T nothing happens if I click on the icon in the launcher. If I 
> long-press and go to "App Info" and click "Open" I get the splash screen for 
> 1-2 seconds then it shuts down. Doesn't help to clear cache/storage. Same 
> behavior after uninstalling and reinstalling.
> 
> On my Pixel 6 I get "App isn't installed" if I just click the icon in the 
> launcher. If I long-press and go to "App info" and click "Open" it starts up 
> just fine. Fetching latest dives from cloud storage worked and browsing the 
> the dives looks good. Didn't do any heavier testing than that though.


So from what I can tell the AppStore forces me to move to API 31. That changes 
the way permissions are handled. In order to do so correctly, I need to change 
the tooling that I use to create the binary. So... yeah, major surgery to the 
build setup.
Nothing impossibly hard, just time consuming and not really what I hoped to 
spend this weekend doing.

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


Re: mobile apps

2023-05-28 Thread Dirk Hohndel via subsurface
The apps are now both available for beta testers.

Something in the required changes to make it past the Google Play rule changes 
apparently completely broke the Android app - it doesn't even start.
Needless to say, the local install prior to those enforced changes actually 
worked - so now I need to debug what went wrong there.
Ugh.

The iOS app appears to work from the store.

/D

> On May 27, 2023, at 16:09, Dirk Hohndel via subsurface 
>  wrote:
> 
> Quick heads-up... after way too long a break (long story), I am in the 
> process of making new mobile apps available.
> 
> The iOS app is under review; a very quick local test seems to indicate that 
> it isn't completely broken - but there's a ton of stuff that I didn't test 
> (downloading from a dive computer, statistics, editing, etc).
> The Android app is still resisting a little more... while I wasn't looking a 
> few requirements for Google Play Store apps have changed and I am chasing 
> those down... but hopefully that will be ready for review as well fairly soon.
> 
> So depending on the speediness of the review teams (it's a holiday weekend in 
> the US, but whom are we kidding, none of the reviewers are in the US...), you 
> should be able to test the two new apps fairly soon. And I would really 
> appreciate somewhat more rigorous tests before I release these to the public.
> 
> 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


mobile apps

2023-05-27 Thread Dirk Hohndel via subsurface
Quick heads-up... after way too long a break (long story), I am in the process 
of making new mobile apps available.

The iOS app is under review; a very quick local test seems to indicate that it 
isn't completely broken - but there's a ton of stuff that I didn't test 
(downloading from a dive computer, statistics, editing, etc).
The Android app is still resisting a little more... while I wasn't looking a 
few requirements for Google Play Store apps have changed and I am chasing those 
down... but hopefully that will be ready for review as well fairly soon.

So depending on the speediness of the review teams (it's a holiday weekend in 
the US, but whom are we kidding, none of the reviewers are in the US...), you 
should be able to test the two new apps fairly soon. And I would really 
appreciate somewhat more rigorous tests before I release these to the public.

Thanks

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


Re: GitHub two-factor authentication

2023-05-19 Thread Dirk Hohndel via subsurface



> On May 19, 2023, at 01:39, Jeroen wrote:
> 
> Btw, read: 
> https://github.blog/2023-03-09-raising-the-bar-for-software-security-github-2fa-begins-march-13/
> which links to 
> https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa
>  for various options.
> 
> Note these are options (outside of the requirement to chose one of them for 
> extra security):
>  FIDO U2F/Webauthn, TOTP and Passkeys etc are all public standards, multiple 
> tools support them, use what you want/like/etc.
> 
> 
> 
> If you do not have TouchID, I heavily suggest getting a Yubikey or Nitrokey 
> for secure authentication, can typically also be used for PGP if one still 
> uses that.
> 
> TOTP is nice, but FIDO U2F is better :)
> 
> iOS Keychain has TOTP built-in btw, though hidden a bit in settings, no extra 
> app needed.
> 
> The GitHub Mobile app is another option to use.
> 

I've had 2FA enabled on my GitHub accounts for quite a while now. In my normal 
workflows I never encounter it. So in order to push via ssh, etc, you don't 
need it.
Occasionally you get asked for it on the web interface, but not really all that 
often. I have a couple of methods enabled - a yubikey, GitHub mobile app, and a 
OTP app on my phone. And I use whatever is most convenient depending on where I 
am / what I'm doing.

I recall maybe once or twice where it felt annoying and "slowing me down", but 
most of the time it felt more like a good indication that I should think 
carefully about what I'm doing (so the need for 2FA is often triggered by 
irreversible actions like deleting a repo or very impactful actions like adding 
a collaborator).

Overall I find it very well implemented.

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


Re: quick hack to fix update check service

2023-02-23 Thread Dirk Hohndel via subsurface


> On Feb 23, 2023, at 01:27, Werner Macho  wrote:
> 
> Hi!
> 
> Also ich würde als Nutzer so etwas einfacher finden und bevorzugen:
> 
> "Eine neue Version ist verfügbar.
> Subsurface-5.0.10 kann hier heruntergeladen werden."
> 
> Subsurface-5.0.10 ist dann die neu verfügbare Version
> und "hier heruntergeladen werden" wäre der Link zur Download Seite.

Wenn ich mich recht erinnere, konnte man (zumindest als ich das Ding
das erste Mal entwickelt hatte) in Dialogboxen keine Links klicken.

Geht das inzwischen?

🤷🏼‍♂️

/D

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


Re: quick hack to fix update check service

2023-02-22 Thread Dirk Hohndel via subsurface
Thanks everyone for the tests. It seems that (language issues aside) this is 
once again working.
Whew. One thing off the plate.

> On Feb 22, 2023, at 02:38, Robert  wrote:
> 
> I also tried to talk to the update server directly both with a web browser 
> and with curl and always get the 
> 
> Latest version is "Subsurface-5.0.10", please check  href="http://subsurface-divelog.org/download";>our downloads page for 
> information on how to upgrade.

Yeah, the server used to reject direct curl access (as it is only intended as a 
backend for the built-in service). This definitely isn't an API that people 
should use.

> even when I GET 
> /updatecheck.html?os=osx&version=5.0.10.82&uuid=ca73c783-0d0b-40f5-92e2-ae062f323bc2
> which is the URL that I captured with wireshark when the latest version of 
> Subsurface asked for it. Strange but should not be one of your worries since 
> that is not an API that is exposed to the users. I only did it because I 
> wanted to see what the update check actually does as I wondered why you do it 
> with some Qt magic rather than about ten lines of perl. Anyway, don’t worry.

I used to have a bit of statistics magic behind this where I used the uuid to 
avoid double counting people and tried to get a rough idea how many folks were 
using Subsurface. But most OSs these days strip out the UUID (assuming that 
they are used for tracking instead of de-duplication... which from a privacy 
point of view makes a lot of sense), and as a result those statistics have 
become completely meaningless - so I removed all of that from the new code.
Which means we can also remove it from the caller, I guess.

And yes, with all that in mind, I should have been able to massively simplify 
the app (I did) and move it to something like node.js or Python or (why?) Perl. 
But given that I'm generally far more comfortable writing C/C++ code and that I 
had working code to borrow from (I just needed to switch to a different 
http-server library - none of the other code that I used made any difference 
between Qt4/Qt5 (or even Qt6 for that matter))... anyway, I just rewrote the 
C++ app since that seemed to be the most likely thing to succeed in a limited 
amount of time. And the result ended up being about 100 lines of code, 
including a bunch of error handling and boilerplate.

/D

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


Re: quick hack to fix update check service

2023-02-22 Thread Dirk Hohndel via subsurface
That is... not the best translation ever.

Mein Deutsch ist nicht mehr ganz so komfortabel - ich lese sehr wenig Deutsch 
und schreibe noch weniger.
Hättest Du eine bessere Übersetzung? Muss ja nicht wort-wörtlich sein, sondern 
einfach nur ein sinnvoller Text für diese Situation...

Danke

/D

> On Feb 21, 2023, at 23:56, Werner Macho  wrote:
> 
> Hi!
> 
> Checked with Subsurface-4.9.3-x86_64.AppImage and 
> Subsurface-5.0.10-x86_64.AppImage on debian bookworm (testing) with the 
> following messages:
> German translation for "bitte auf unserer Programme herunterladen Seite 
> nachlesen" sounds a bit "holprig" ;)
> 
> In that term I would at least set "Programme herunterladen" under quotes.
> 
> regards
> Werner
> 
> 
> On Wed, Feb 22, 2023 at 2:58 AM Dirk Hohndel via subsurface 
>  <mailto:subsurface@subsurface-divelog.org>> wrote:
>> 
>> I think I have something that works - but it could really benefit from some 
>> testing.
>> 
>> Would people mind running old and new versions of Subsurface (on Linux, 
>> macOS, and Windows) and check for an update (that's under the Help menu 
>> entry)?
>> Does the response make sense? If not, what does it say, what should it say.
>> 
>> In order to get a feel for how much this has tested, would you also send 
>> "success" emails (including what combinations you tested)?
>> 
>> Thanks
>> 
>> /D
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org <mailto: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


quick hack to fix update check service

2023-02-21 Thread Dirk Hohndel via subsurface


I think I have something that works - but it could really benefit from some 
testing.

Would people mind running old and new versions of Subsurface (on Linux, macOS, 
and Windows) and check for an update (that's under the Help menu entry)?
Does the response make sense? If not, what does it say, what should it say.

In order to get a feel for how much this has tested, would you also send 
"success" emails (including what combinations you tested)?

Thanks

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


Re: Is it SmartTrak, Smartrak, or Smarttrack or...

2023-02-20 Thread Dirk Hohndel via subsurface
Salva,

Would it make sense to try to clean this up everywhere - or is this just legacy 
and not worth the effort?

/D

> On Feb 20, 2023, at 11:12, Salvador Cuñat  wrote:
> 
> Hi Dirk.
> 
> SmartTrak is the correct spelling for the software. That was my fault from 
> the very beginning, as I even misspelled the name in the code files.
> 
> Btw, LogTrak is the new (well, not that new) divelog from Scubapro. Java 
> based and using HSQLDB to create on the fly databases, completely different 
> format.
> 
> I have an importer for LogTrak too (and another for the ASD binary format 
> used by Scubapro's softwares to import/export) but never find time to put 
> them in line with Subsurface's master and send a PR. Probably in the next 
> weeks will have some time to end this work and send a PR once you have cut 
> the current planned release.
> 
> Best regards.
> 
> Salva.
> 
> 
> El lun., 20 feb. 2023 18:49, Dirk Hohndel  > escribió:
>> I noticed that we are a wee bit inconsistent in how we spell this thing.
>> Mind you, it seems the vendor has abandoned it in favor of LogTrak (and I'm 
>> not sure if that uses the same format), but a translator pointed out that 
>> apparently it should be spelled with two 't's and we in most places spell it 
>> with one...
>> 
>> Salva, what's the official word on this? :)
>> 
>> /D

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


  1   2   3   4   5   6   7   >