OpenCPN Build on Debian

[nohal]

Hamish,
I've also added architecture detection in my git repo at https://github.com/nohal/OpenCPN/blo...CMakeLists.txt
Don't know exactly how the debian packages get built, but it could also be useful for you.

Pavel

[antonm]

Originally Posted by HamishB

resubmit to the mentors area for another review? have we ticked all the boxes from their last look at it?

I believe we still need to make it use geodata that exists in the Debian like WVS files from xtide package. I will be able to help with this, but only around the end of this week. Here is summary:

1. xtide-coastline package ships /usr/share/xtide-wvs/wvs1.dat. I have asked on this forum some time ago and it is ok to just patch the filename within OpenCPN source code to use this resolution file. So, no problems with this item.

2. Harmonic data. Here we still have problems with different formats as OpenCPN cannot directly use files from xtide-data and xtide-data-nonfree packages.

- Anton

[HamishB]

Originally Posted by nohal

I've also added architecture detection in my git repo at https://github.com/nohal/OpenCPN/blo...CMakeLists.txt
Don't know exactly how the debian packages get built, but it could also be useful for you.

I've never had a problem with that, for me compiles have always "just worked" on both amd64 and i686 without having to do anything special. I assume cmake just takes from `uname -m` in Linux if it needs to know about the architecture.

I would proceed on a "leave as-is unless breakage is reported" path, and wait & just see what happens when it tries to build for Arm etc.


Hamish

[nohal]

Hamish,
I would be a bit surprised if cmake changed all those hardcoded arch=i386 thingies. I think, that we are not building 64-bit until you change all i386 to amd64 (as suggested in the build instructions) or let the autodetection do it for you. I agree it is not a big deal.

Pavel

[HamishB]

Originally Posted by nohal

I would be a bit surprised if cmake changed all those hardcoded arch=i386 thingies. I think, that we are not building 64-bit until you change all i386 to amd64 (as suggested in the build instructions) or let the autodetection do it for you.

ah, I was not aware that was hardcoded in CMakeLists.txt.

Then yes, it should determine arch at build time automatically, is `uname -m` POSIX (work on a Mac)?

I agree it is not a big deal.

I doubt OpenCPN will deal with large-files or integers that big in normal operation.


shrug,
Hamish

[HamishB]

Originally Posted by antonm

I believe we still need to make it use geodata that exists in the Debian like WVS files from xtide package. I will be able to help with this, but only around the end of this week.

fwiw I don't consider these blockers for uploading, only issues to be at the top of the wish-list: split out data into opencpn-data package; better yet depend on existing data packages.

Here is summary:

1. xtide-coastline package ships /usr/share/xtide-wvs/wvs1.dat. I have asked on this forum some time ago and it is ok to just patch the filename within OpenCPN source code to use this resolution file. So, no problems with this item.

the reason I don't find this one a blocker is that I think that DebianGIS as a team need to come up with a strategy for getting gmt/zygrib/opencpn/xtide to all use the same format of the GSHHS data instead of each shipping their own.
Using xtide's is a suitable quick fix, but I propose using GMT's as the best developed and longest standing of them. But first the high-res GMT coastline should be a package and not a download script.

does just patching the filename to use the xtide one, and not installing the opencpn one work?

2. Harmonic data. Here we still have problems with different formats as OpenCPN cannot directly use files from xtide-data and xtide-data-nonfree packages.

ok, but is it a blocker?
(note to self: finish off my script to rederive NZ tidal station constituents and donate back to upstream xtide [who threw out a number of "free for any use" metadata'd NZ stations from their Free package in a bulk purge of all non-US things. argh])


Hamish

[nohal]

Hamish,
`uname -m` is useless when you build in 32-bit chroot for example, so the "standard" way cmake people detect architecture is by cmake_sizeof_void_p check. That's what I used as well.
I have very little idea on how things work on Mac, never even touched one

Pavel

[antonm]

Originally Posted by HamishB

fwiw I don't consider these blockers for uploading, only issues to be at the top of the wish-list: split out data into opencpn-data package; better yet depend on existing data packages.

Well, of cause we can try and resubmit to mentors one more time and comment that we will work on a better solution for this. And probably that should work since it is not only OpenCPN related.

Originally Posted by HamishB

does just patching the filename to use the xtide one, and not installing the opencpn one work? ok, but is it a blocker?

Yes, here is my thread on this http://www.cruisersforum.com/forums/...dat-53182.html

In this case I would say that we should handle this since we can directly use wvs1.dat shipped in Debian and it looks to a simple patch.

I recalled another thing that we should do before the push, we need to split data files we distribute and probably including the docs to separate package/packages (actually all non architecture dependent files should be there).

[SethDart]

HI,

Two weeks ago I created a patch to add ARCH option to cmake:
https://github.com/OpenCPN/OpenCPN/c...f75f79fab6c00d

That will ease work for packagers. No more need to edit CMakeList.txt

I did not chose to autodetect because of the need to cross compile. But the begining (default to i386) could be changed to autodetect.

[HamishB]

I think we'd drop it, but fwiw if remaining, probably /usr/share/opencpn/wvsdata/readmewvs.txt should be moved to /usr/share/doc/opencpn/copyright.

I just tested and a missing /usr/share/opencpn/wvsdata/ dir is non-fatal, just less helpful. Only repercussion I can see is this line in ~/opencpn.log:
"Unable to open WVSChart datafile: /usr/share/opencpn/wvsdata/wvs43.dat"
So I think we can just patch the path and either Suggests: or Recommends: the xtide-coastline package. Any opinion on which of those two to use?

Patch to use the more detailed 1:1m xtide coastline wvs1.dat applied in DebianGIS svn r2980. The 1:43m wvs43.dat is so jagged I don't miss it one bit, IMHO it's worth the disk-space cost of a single extra BSB chart to get a world-wide respectable coastline.
The .deb is now down to 11mb.


fwiw /usr/share/doc/opencpn/doc takes up 6.9mb, and at least the biggest image is reported as already optimized by `optipng` (already smoothed/antialiased; so maybe better as jpg?). I don't know exactly what needs to be done to split out the docs into a 'opencpn-doc' package. I know we've got to add the package info at the end of the control file, but what needs to happen in rules?


Hamish


ps- my workflow:

dquilt new use_xtide_coastline.patch
dquilt add src/chart1.cpp
# make edits to chart1.cpp
dquilt add src/wvschart.cpp
# make edits to wvschart.cpp
dquilt refresh
dquilt header -e
.add patch comments.

cd debian
svn add patches/use_xtide_coastline.patch
vi control
vi rules
dch -a ".add changelog comments."

#test build
debuild clean
debuild -i -uc -us -b
sudo dpkg ../opencpn_2.4.412-1_amd64.deb

[HamishB]

Help->License tab and Help->Documentation tab now work correctly in the debiangis package.

Hamish

[HamishB]

Originally Posted by nohal

`uname -m` is useless when you build in 32-bit chroot for example, so the "standard" way cmake people detect architecture is by cmake_sizeof_void_p check. That's what I used as well.

ah, ok.

for debian there is this to play with when cross-compiling (etc.):

$ dpkg-architecture
DEB_BUILD_ARCH=amd64
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=amd64
DEB_BUILD_ARCH_BITS=64
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=x86_64
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=x86_64-linux-gnu
DEB_HOST_ARCH=amd64
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=amd64
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=x86_64-linux-gnu

e.g.

DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

or I guess you could just use "eval `dpkg-architecture`".


that does not preclude cmake figuring it out for itself of course, which may have other benefits.


Hamish

[bdbcat]

Hamish....

I have completely lost the flow of this thread....

Will you kindly summarize what I need to do upstream to support your efforts?

Comment on xtide data:
The harmonic data currently shipping in sourceforge git have been tweaked (by me and others) to work nicely in the US, especially fixing current direction reporting. We are also soon adding Scandinavian tide staion support. Using a generic xtide harmonic file will be less useful for many users. I think we need to continue to package our own harmonic files. Maybe they need to be renamed to avoid collision with the generic files?

Related point: I tested some code to incorporate the newer binary xtide data sets. This could be made to work, but I have no immediate motivation to pursue.

Thanks
Dave

[HamishB]

Originally Posted by bdbcat

Will you kindly summarize what I need to do upstream to support your efforts?

here is the current patch set:
[pkg-grass] Index of /packages/opencpn/trunk/debian/patches


there are some patches earlier in this thread to consider for inclusion in the main git repo.

nohal's don't use embedded zlib,bzip on UNIX patch (slightly edited by me) can be found in "rm_embedded_zlib.patch" in the link above. see also Pavel's version in FlySpray#407.

nohal (comment #121 above) and SethDart (comment #129 above) include patches for architecture detection. So far Anton & I haven't applied that in the deb packaging, and I can build on amd64 without a problem, but I'm guessing that will fail for the Arm, RISC, PPC,Mips,... Debian builds.

see post #132 about using `dpkg-architecture` to detect architecture on debian, if needed.

Comment on xtide data:
The harmonic data currently shipping in sourceforge git have been tweaked (by me and others) to work nicely in the US, especially fixing current direction reporting. We are also soon adding Scandinavian tide staion support. Using a generic xtide harmonic file will be less useful for many users. I think we need to continue to package our own harmonic files.

I think it may be enough to quote the above explanation in the package at /usr/share/doc/opencpn/README.harmonics.

Maybe they need to be renamed to avoid collision with the generic files?

there's no filesystem conflict as they live in /usr/share/opencpn/. it's just a matter of redundancy.

Related point: I tested some code to incorporate the newer binary xtide data sets. This could be made to work, but I have no immediate motivation to pursue.

FWIW Debian frowns on binary blobs from upstream (they are hard to modify/adapt), so OpenCPN's ascii version of the table is probably preferable as a source. I think the "Debian way" method would be for the binary conversion to happen by a script at build time (or install time).


Also [nothing for you to do about it, but fyi] harmonic data and ships bells will get put into a arch-independent opencpn-data package, but I'm still struggling to figure out how to do that for opencpn-doc. I looked for a wxMedia fn to allow us to ship 200kb .ogg instead of 2mb .wav files, but the only one I could find relied on the operating system already supplying the codec, which for vorbis is probably not present on most MS Windows and Mac systems, so no joy.


thanks,
Hamish

[HamishB]

Hi,

DebianGIS svn now updated for 2.4.423 and arch-independent opencpn-data and opencpn-doc have been split off.

todo:
* deal with hardcoded i386 in CMakeLists.txt, but actually I don't think that matters -- I think that only comes into play when you use cmake to make the .deb. Debian's package building tools detect that info on their own and don't use cmake's .deb creation method. I didn't touch it but it still made a working amd64 package anyway, so I think it's ok as-is:

$ file /usr/bin/opencpn 
/usr/bin/opencpn: ELF 64-bit LSB executable, x86-64 ...

* README.harmonics gets installed twice, need to remove the copy from the opencpn-doc package, keep the copy in the opencpn-data package.

* README_BELLS.txt should probably be renamed README.bells (at which point debian's pkg building tools may gzip it automatically)


... in other words: are we there yet?

Hamish