Beta Test / Technical

[P_Dub]

It does not mean that you can not do anything to show th current.
Thanks anyway.

[P_Dub]

to the one who made this program:- can you tell me why the current made for the Dardanelles and Boshphores (Turkey) can not be align as indicated in the idx file? All others current points works correctly, but not there.

[bdbcat]

P_Dub...
Please post the index file, and I will take a close look


Dave

[P_Dub]

I will send you part of the HARMONIC and HARMONIC.IDX that I have rebuild with reduce constituents (67 + mean level) if you send me your email.
pierdube@videotron.ca

[P_Dub]

[QUOTE=bdbcat;3611329]P_Dub...
Please post the index file, and I will take a close look


Dave, did you get the message with the 2 files?
Thanks for help.

[bdbcat]

P_Dub...
I got the files.
Two problems:
1. To show current direction, the current station definition must be a "slave" station (little c) and include a reference to a master station (big C). They can have the same names, if desired.
2. Line format of IDX line starting with "^" is very fussy. I found an extra space before the reference station name.


Putting this together, here is the IDX entries required for one station in your IDX file.

CAsi:Tur:Ist:    029.1127  41.2017  +3:00 KARSIKUM Current, Turkey
cAsi:Tur:Ist:    029.1127  41.2017  +3:00 KARSIKUM Current, Turkey
^+05   1.0 0 +00  1.00  0 0001 044 224 1 KARSIKUM Current, Turkey

I'm sure you can complete the rest.


Good Luck
Dave

[P_Dub]

Many thanks Dave. It's all corrected, all we needed to do is replacing the C by c and that extra space was the problem. I had change the c by C to show the arrow. I don't know why I had not seen it. I made more than 500 around the world without problem. I have re-analyse and rebuild properly more than 4300 points around the world and all working OK (comparing with tide tables of various country). So if you are interrested, I can email you the whole thing for yourself.
Have a good day.

[LennartG]

Trying to patch colors and symbols for s57 and are using the default patch location for o-charts. Patching symbols works fine but colors does not.
My color patch file looks like this:

<chartsymbols>
<color-tables>
<color-table name="DAY_BRIGHT">
<graphics-file name="rastersymbols-day.png"/>
<color name="CHBRN" r="247" g="238" b="205"/>
<color name="LANDA" r="255" g="239" b="132"/>
<color name="LANDF" r="247" g="239" b="206"/>
<color name="CSTLN" r="0" g="0" b="0"/>
<color name="SNDG1" r="7" g="7" b="7"/>
<color name="SNDG2" r="7" g="7" b="7"/>
<color name="DEPSC" r="125" g="130" b="247"/>
<color name="DEPCN" r="125" g="130" b="247"/>
<color name="DEPDW" r="255" g="255" b="255"/>
<color name="DEPMD" r="227" g="235" b="255"/>
<color name="DEPMS" r="198" g="215" b="255"/>
<color name="DEPVS" r="132" g="158" b="255"/>
</color-table>
</color-tables>
</chartsymbols>

and loads correct according to the OpenCPN log, at least no error messages. The colors are however not updated accordingly.
Something silly I'm sure.

[stevead]

All of my flatpak builds are failing on CircleCI. All the other CircleCI builds (MacOS, Focal, Buster, Bionic etc.) are OK.

Here is the snippet of the error message

FB: Running: git config --get user.email
FB: Running: git config --get user.name
FB: Running: flatpak info --arch=x86_64 --show-commit org.freedesktop.Sdk//20.08 beta
FB: Running: flatpak info --show-location --arch=x86_64 org.freedesktop.Sdk//20.08 beta
FB: Running: flatpak info --arch=x86_64 --show-commit org.opencpn.OpenCPN beta
Downloading sources
]2;flatpak-builder: Downloading twocan_pluginFB: Running: git --version
FB: Git version: 2.28.0.0
FB: Running: git init --bare /home/circleci/project/build/flatpak/.flatpak-builder/git/git_github.com_TwoCanPlugIn_TwoCanPlugIn-1IP5L1
Initialized empty Git repository in /home/circleci/project/build/flatpak/.flatpak-builder/git/git_github.com_TwoCanPlugIn_TwoCanPlugIn-1IP5L1/
FB: Running: git remote add --mirror=fetch origin git://github.com/TwoCanPlugIn/TwoCanPlugIn
FB: Running: git cat-file -e gateway
FB: Running: git ls-remote origin
fatal: remote error: 
  The unauthenticated git protocol on port 9418 is no longer supported.
Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.
Failed to download sources: module twocan_plugin: Child process exited with code 128
make[3]: *** [CMakeFiles/flatpak-build.dir/build.make:58: CMakeFiles/flatpak-build] Error 1
make[2]: *** [CMakeFiles/Makefile2:106: CMakeFiles/flatpak-build.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:113: CMakeFiles/flatpak-build.dir/rule] Error 2
make: *** [Makefile:131: flatpak-build] Error 2

Exited with code exit status 2
CircleCI received exit code 2

The config.yml file and circleci-build-flatpak.sh script are from Jon Gough's testplugin_pi.

Any thoughts ?

[nohal]

Steve, from the error it seems like your build workflow simply tries to access github in a way they deprecated and removed, I would probably try to update it to the current state of the shipdriver template - https://github.com/OpenCPN/OpenCPN/discussions/2589

[rgleason]

Originally Posted by stevead

All of my flatpak builds are failing on CircleCI. All the other CircleCI builds (MacOS, Focal, Buster, Bionic etc.) are OK.

...
The config.yml file and circleci-build-flatpak.sh script are from Jon Gough's testplugin_pi.

Any thoughts ?

Jon has a new version coming out, you could look at his testplugin_pi updates branch. https://github.com/jongough/testplugin_pi/tree/updates


You could use the config.yml and ci from that.

[stevead]

Perusing some of the CircleCi flatpak build messages prior to the error is this

sources:
       - type: git
         url: git://github.com/TwoCanPlugIn/TwoCanPlugIn
         branch: gateway

I'm guessing this could be the offender and it should really be https:

Any idea where the git url set in the cmake files ? Doesn't seem obvious to me.

Thanks.

[stevead]

Found it.

In cmake/in-files/org.opencpn.OpenCPN.Plugin.yaml.in Ensure that the git url is correctly prefixed, changed from git to https

sources:
       - type: git
         url: https://${GIT_REPOSITORY_SERVER}/${GIT_REPOSITORY}
         ${GIT_BRANCH_OR_TAG}: ${GIT_REPOSITORY_ITEM}

F..k, Could you guys design a more obfuscated build process? After having a look at Mike's Shipdriver config files, there's probably no limit!

The more obfuscated, the more brittle and the harder it is to maintain.

[nohal]

Originally Posted by stevead

Found it.

In cmake/in-files/org.opencpn.OpenCPN.Plugin.yaml.in Ensure that the git url is correctly prefixed, changed from git to https

sources:
       - type: git
         url: https://${GIT_REPOSITORY_SERVER}/${GIT_REPOSITORY}
         ${GIT_BRANCH_OR_TAG}: ${GIT_REPOSITORY_ITEM}

F..k, Could you guys design a more obfuscated build process? After having a look at Mike's Shipdriver config files, there's probably no limit!

The more obfuscated, the more brittle and the harder it is to maintain.

If you think it can be done better, submit a pull request, I will gladly merge it...

[chris95040]

Originally Posted by stevead

The more obfuscated, the more brittle and the harder it is to maintain.

Exactly right! The idea that complexity has a cost that needs to be justified never seems to occur to amateur programmers, they just type and type and type... I guess you get what you pay for.