Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 18-04-2011, 04:09   #121
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,016
Re: OpenCPN Build on Debian

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
__________________

__________________
nohal is online now   Reply With Quote
Old 18-04-2011, 04:29   #122
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
Re: OpenCPN Build on Debian

Quote:
Originally Posted by HamishB View Post
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
__________________

__________________
antonm is offline   Reply With Quote
Old 19-04-2011, 23:17   #123
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Re: OpenCPN Build on Debian

Quote:
Originally Posted by nohal View Post
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
__________________
HamishB is offline   Reply With Quote
Old 20-04-2011, 01:11   #124
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,016
Re: OpenCPN Build on Debian

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
__________________
nohal is online now   Reply With Quote
Old 20-04-2011, 01:41   #125
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Re: OpenCPN Build on Debian

Quote:
Originally Posted by nohal View Post
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)?

Quote:
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 is offline   Reply With Quote
Old 20-04-2011, 01:52   #126
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Re: OpenCPN Build on Debian

Quote:
Originally Posted by antonm View Post
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.

Quote:
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?

Quote:
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
__________________
HamishB is offline   Reply With Quote
Old 20-04-2011, 01:59   #127
Registered User

Join Date: Feb 2010
Location: On the go. Not in Prague.
Posts: 4,016
Re: OpenCPN Build on Debian

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
__________________
nohal is online now   Reply With Quote
Old 20-04-2011, 02:22   #128
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
Re: OpenCPN Build on Debian

Quote:
Originally Posted by HamishB View Post
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.

Quote:
Originally Posted by HamishB View Post
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 wvschart.cpp Code and Hard-Coded wvs43.dat

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).
__________________
antonm is offline   Reply With Quote
Old 20-04-2011, 02:57   #129
Registered User

Join Date: Mar 2010
Location: Normandy, France
Boat: Flush Poker, 8.25m (Point Barre)
Posts: 335
Re: OpenCPN Build on Debian

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.
__________________
SethDart is offline   Reply With Quote
Old 20-04-2011, 06:38   #130
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Re: OpenCPN Build on Debian

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:
Code:
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 is offline   Reply With Quote
Old 20-04-2011, 07:11   #131
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Re: OpenCPN Build on Debian

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

Hamish
__________________
HamishB is offline   Reply With Quote
Old 21-04-2011, 06:18   #132
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Re: OpenCPN Build on Debian

Quote:
Originally Posted by nohal View Post
`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.):
Code:
$ 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.
Code:
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
__________________
HamishB is offline   Reply With Quote
Old 21-04-2011, 11:50   #133
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,883
Re: OpenCPN Build on Debian

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
__________________
bdbcat is online now   Reply With Quote
Old 21-04-2011, 18:15   #134
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Re: OpenCPN Build on Debian

Quote:
Originally Posted by bdbcat View Post
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.

Quote:
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.

Quote:
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.

Quote:
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 is offline   Reply With Quote
Old 24-04-2011, 21:57   #135
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
Re: OpenCPN Build on Debian

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:
Code:
$ 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
__________________

__________________
HamishB is offline   Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenCPN Build on Win32 Thorac OpenCPN 108 13-06-2011 06:56
OpenCPN bdbcat OpenCPN 1343 19-09-2009 16:59
OpenCPN with BSB v4 selkie Navigation 4 03-08-2009 12:32



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 13:50.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.