OpenCPN Build on Debian

[HamishB]

Originally Posted by antonm

Besides my repository I have uploaded to mentors for now: mentors.debian.net

great!

What will be my steps to get access to Alioth tree? I am on the DebianGIS lists.

see:
http://wiki.debian.org/DebianGis
http://wiki.debian.org/DebianGis/InfoForDevelopers
http://wiki.debian.org/DebianGis/Sponsoring

I have just created an opencpn/ area for you at svn.debian.org.

http://svn.debian.org/viewsvn/pkg-grass/packages/opencpn/trunk/

Register yourself a -guest account ("guest" means non-DD) and post to DebianGIS introducing yourself and asking that your alioth account name be activated for the repo. Frankie has to do the activation, you can also find him on IRC, the channel is #debiangis at OFTC.


Hamish

[cagney]

antonm
I installed and quickly tested your debian package on Kubuntu 9.10. Everything seems to work OK!
Do you mind if I add your package to the download page on opencpn.org ?

Thomas

[idpnd]

Originally Posted by antonm

Hooray! First Debian package is ready for testing, I published it in my repository.

Impressed!

[antonm]

Originally Posted by HamishB

Debian takes longer because it requires to pass a higher threshold of peer review.

I must tell that we are way from having package in Linux distribution for now since we are not passed peer review yet. Same applies to Ubuntu and other Linux distributions.

Here is the link to review results from Debian Developer:

Re: RFS: opencpn

As you see there are a couple of issues including technical and licensing. I started creating bugs at SourceForge from licensing ones as must critical.

There are a couple of files in OpenCPN that either have unclear license header or license not suitable to be linked with GPL 2 code like ones that do not explicitly grant copy, modify and distribution rights. Or ones that have non-commercial clauses in it. There are also non free sounds and not clear licensed data files.

For now I just created those tickets, but also start digging for anything that I can propose at the moment.

[antonm]

Originally Posted by cagney

Do you mind if I add your package to the download page on opencpn.org?

I certainly do not mind. It is even better when people start using it as soon as possible to catch any bugs.

Just note there that this is an unofficial package yet. There are issues that we need to address before we can be included into Linux distribution.

I posted separate message here with the link to peer review.

[idpnd]

I am very impressed with the work that goes into the packaging/review system!

src/grib/bzip2 contains an embedded code copy of bzip2. Please ask upstream to remove it from the tarball. Same for src/grib/zlib-1.2.3. Software maintained elsewhere should not be in the tarball. [...] If the reason that they are in the tarball is for operating systems like Windows that don't have good packaging/repository/dependency systems, I'd suggest making a separate tarball containing tarballs for all the dependencies.

That's rather annoying - lot's of fiddling I guess?

data/sounds/alarm2.wav contain these comments:
Copyright . Cinematronics 1995
Microsoft Plus! . for Windows 95

This is easily solved by taking some public domain/cc files instead. Incidentally, sound has never worked for me on linux in the first place

In addition, I found some spam on the upstream website:

That's a bit annoying, there's a drupal nofollow module which would probably cut out the motivation a bit

You have enough work above, but have you also considered packaging wxTide, CapCode and other FLOSS nautical apps?

Capcode is hugely enjoyable actually.

[Psyches]

Originally Posted by antonm

I must tell that we are way from having package in Linux distribution for now since we are not passed peer review yet. Same applies to Ubuntu and other Linux distributions.

Here is the link to review results from Debian Developer:

Re: RFS: opencpn

As you see there are a couple of issues including technical and licensing. I started creating bugs at SourceForge from licensing ones as must critical.

There are a couple of files in OpenCPN that either have unclear license header or license not suitable to be linked with GPL 2 code like ones that do not explicitly grant copy, modify and distribution rights. Or ones that have non-commercial clauses in it. There are also non free sounds and not clear licensed data files.

For now I just created those tickets, but also start digging for anything that I can propose at the moment.

Thanks, Anton. The review results are especially helpful. As I mentioned in PM, Dave will need to take a look, think, propose, etc. Not much will happen on this front until Dave gets the time, but as you say there are things others can do in advance. Also as I mentioned, you marked the bugs as medium. If you think that is too low prio, feel free to adjust.

Mark

[antonm]

Originally Posted by idpnd

That's rather annoying - lot's of fiddling I guess?

Usually such things are not included and the source is just linked with external library (same as we link with wxWidgets and glib). I saw sources in my life that finally end up with having around 1 Gb of external libraries going shipped with them. Obviously after a time it becomes harder to upgrade to newer versions of such libraries and those simply goes as is and unmaintained.

However we need to recall the reason of why it was done this way and discuss if a better approach can be taken.

Originally Posted by idpnd

This is easily solved by taking some public domain/cc files instead. Incidentally, sound has never worked for me on linux in the first place

The only things to consider that some licenses (including pre version 3 CC ones) are not considered DFSG free and cannot be shipped in Debian main:

DFSGLicenses - Debian Wiki

It still may be shipped in non-free, but since we have opportunity to make it DFSG free I think we just need to pickup sounds under DFSG compatible licenses (CC-BY-SA 3 is safe) or public domain ones.

Here are some links to sound libraries:

public domain sounds | free sound library
Free sound samples - OLPC

[antonm]

Originally Posted by Psyches

Also as I mentioned, you marked the bugs as medium. If you think that is too low prio, feel free to adjust.

From first sight priority is not that much used since everything is of 5 - Medium priority. I adjusted them to 6, so they are on top of others. In my opinion license issues are very important as we declare to be licensed under GPL 2.

[Psyches]

Originally Posted by antonm

Usually such things are not included and the source is just linked with external library (same as we link with wxWidgets and glib). I saw sources in my life that finally end up with having around 1 Gb of external libraries going shipped with them. Obviously after a time it becomes harder to upgrade to newer versions of such libraries and those simply goes as is and unmaintained.

However we need to recall the reason of why it was done this way and discuss if a better approach can be taken.

As someone noted, at least part of the reason is to have easy access on other platforms, e.g. Windows. I've suggested that we restructure the code base to better accommodate platform separation, and this is a fine example of a benefit of that restructuring. I do believe the various bits of source code need to be provided in the opencpn project, rather than lots of instructions on how to cobble together a working version for (e.g.) Windows. Of course a downside of keeping the source directly is that the included copies need periodic updating to stay up-to-date. Another alternative is to move to maven, if the source is available in public repository.

Originally Posted by antonm

I adjusted them to 6, so they are on top of others. In my opinion license issues are very important as we declare to be licensed under GPL 2.

Agreed - that's why I mentioned it.

Mark

[Psyches]

Originally Posted by cagney

There is no guarantee for the location of the cm93 chart dictionary. I think that one point in Dave's code is, to not make any assumptions in this case. This has been in response to 'bug' reports, and difficulties from some users.

Check this post by Dave http://www.cruisersforum.com/forums/...tml#post306241
and prior posts by "Tia Bu" who raised the subject, for a back ground to the present code.

Ok, a fix is checked in - I've done as much testing as I can. So folks, please try it out & let me know.

Thomas, thanks for the background - made a big difference. The full tree search is done (using Traverse as I mentioned), but I added an extra LC test at the beginning where the code was already checking where things "should be". So hopefully perf will be better than before for most folks with filesystems mounted to return LC names as Hamish mentioned. I mainly did point-fixes though, rather than anything fancier.

Mark

[HamishB]

Originally Posted by antonm

As you see there are a couple of issues including technical and licensing.

Actually I am quite encouraged by Paul's review. None of the problems are
fundamental and cannot be overcome by a series of small fixes.

> data/sounds/alarm2.wav contain these comments:

This is easily solved by taking some public domain/cc files instead.

may I suggest someone take their cell phone voice memo recorder and
make a short sample of their ship's bell, or similar?


I'd note that newer versions of libS52 are GPL3. OpenCNP is not using
that newer version yet, but I hope it will, as there are many new
improvements.


common things like zlib and bzip2 should not be mirrored. There is a good
case for hosting really exotic stuff which might be hard to find or go away.
anyway anything that needlessly adds to the maintanence burden should be avoided.


Paul:
> Debian -- Package Search Results -- zygrib

hey, zyGrib made it into Debian! I hadn't noticed that. excellent news.


Paul:
> src/georef.c has this non-free license (non-commercial use/etc is non-free):
> Similar for gpc.h georef.h

there is plenty of good (if not best!) geo-code available in projects
like PROJ.4 and GDAL which can be freely reused. I'll have a look at what the above
source files do an report back.


regards,
Hamish

[antonm]

Originally Posted by Psyches

As someone noted, at least part of the reason is to have easy access on other platforms, e.g. Windows. I've suggested that we restructure the code base to better accommodate platform separation, and this is a fine example of a benefit of that restructuring. I do believe the various bits of source code need to be provided in the opencpn project, rather than lots of instructions on how to cobble together a working version for (e.g.) Windows.

One of proposals was to have those dependencies distributed as a separate archive. Than it will just look like extracting it to some predefined "ext" folder within the OpenCPN.

In least case we may just adjust Makefiles to support building with external libraries, based on some switch value or whatever.

Any concerns against those proposals?

[antonm]

Originally Posted by HamishB

there is plenty of good (if not best!) geo-code available in projects like PROJ.4 and GDAL which can be freely reused. I'll have a look at what the above source files do an report back.

That wold be very helpfull.

I got access to Debian GIS svn, on nearest weekend I will sort out current "debian" folder and submit it there, it contans existing patches that I made primary to Makefiles. More patches to come from me. I will add exisiting patches to OpenCPN sourceforge for upstream inclusion.

[HamishB]

Originally Posted by antonm

That wold be very helpfull.

I got access to Debian GIS svn, on nearest weekend I will sort out current "debian" folder and submit it there, it contans existing patches that I made primary to Makefiles. More patches to come from me. I will add exisiting patches to OpenCPN sourceforge for upstream inclusion.

excellent.


II had a look at georef.c/.h and as far as I can tell between PROJ.4, PROJ.4/Gerald E.'s "geod" program for great circle calcs, and GRASS GIS's GPL datum tables and DMS string functions everything is pretty much covered, and by more mature code ta boot. It will take some work to replace, but the end result will give us a more much robust product.
To be honest I don't think it will be that bad. Maybe the string functions will need a little new coding, but that's trivial compared to the projection code. (please please please use PROJ.4 instead of writing something ourselves)


as far as I can see nothing actually uses include/gcp.h, so it doesn't need to be there.


Hamish