OpenCPN Build on Debian

[cagney]

Originally Posted by 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.
.....
......
Hamish

I can confirm this. I build the Ubuntu packages for OpenCPN and only have to change i386 to amd64 in CMakeLists.txt when building a .deb package, with cmake. Compiling for local use on my computer is never a problem.

Where can I find Debian packages to publish on OpenCpn.org?

Thomas

[HamishB]

Originally Posted by cagney

Where can I find Debian packages to publish on OpenCpn.org?

I haven't tried it, but the Ubuntu 10.04 packages are close enough in vintage to Debian/stable (squeeze) to probably 'just work'; install using gdebi or dpkg -i.

virtual-machine-light: On an ubuntu system it's fairly straight forward to create a debian/stable chroot environment (or two if you want 32/64 bit versions) in which to build the packages. details available upon request.

a heaver approach is to install debian in a full VM (kvm-qemu, virtualbox, ...) and build from there. details available upon request.

Install the devscripts package and all that it recommends, git pull a fresh copy of opencpn, then from within the main opencpn source tree dir:

svn co svn://svn.debian.org/pkg-grass/packages/opencpn/trunk/debian debian
debuild -i -uc -us -b
# whiz bang whirl
ls ..

Or I can just send you a copy of an all-in-one version I've built.

One day you'll able to point to http://packages.debian.org/opencpn and http://packages.ubuntu.com/opencpn directly. (debian packages semi-automatically flow into ubuntu)


Hamish

[HamishB]

Hi,

I'm just looking through last year's package review feedback: Re: RFS: opencpn

One unchanged item since last time is the presence of src/mygdal and src/myiso8211 (also belonging to GDAL/OGR). Does the possibility exist to simply link to libgdal as an optional switch, or do opencpn's versions of those include local customizations which would make that impossible/very difficult?

$ ogrinfo --formats | grep S57
  -> "S57" (read/write)
$ gdalinfo --formats | grep BSB
  BSB (ro): Maptech BSB Nautical Charts

?

thanks,
Hamish

[bdbcat]

Hamish....

We could use libgdal, with what I would call "moderate" effort, with some loss of functionality.

There are good reasons not to. libgdal is very capable, but not optimum for dynamic GUI based systems like ours. Its great for generating static data from S57 cells.

I tweaked some of the code to compile on Windows, eliminate redundancy, reduce memory footprint, fix some obvious bugs present in the version I started with, and add call backs to support Progress Dialogs on SENC creation.
In theory, these fixes should go upstream to GDAL. In practice, though.....

IMHO, this kind of improvement for a specific application should not block debian repo inclusion. Otherwise we wear a ball and chain, and innovation is stifled.

Thanks
Dave

[HamishB]

Hi,

one thing I hadn't noticed before Paul's latest review were the .exe and .dll binaries in the buildwin/ directory. Now, as part of their effort to adhere to the GPL, in part to avoid 404 errors from the only known source of various upstream-abandoned packages, and I suppose in part simply because they are in a position to offer the service to the community, Debian as-policy hosts a copy of the original tarball of each and every package they ship on the respective package page. One thing that falls out of that is that it's not enough for the packages they distribute to be free of any copyright liabilities thanks to the package build rules chopping stuff out; the organization also needs to legally protect itself from any undistributable stuff in the source tarballs too.

so the inconvenient question is- who owns copyright on those exe and dlls, and do Debian (or opencpn.org for that matter) have all the boxes ticked to be allowed to redistribute, or even just host copies them? An obvious, but less end-user-friendly, solution is a second tarball/git repo hosting any problematic stuff which the legally adventurous can dive into if they dare.

where do we stand?

thanks,
Hamish

ps- I know that some parts of the review seem rather more pedantic than others, but especially for things like fixing compiler warnings, and getting rid of things which could potentially get us shut down if we ever got big enough to be viewed as a threat to someone's business model, I view the review process as eating our veggies- i.e. in the long run good for us even if it's a total PITA right now.

[nohal]

Hamish,
Is there a problem just removing the wxWidgets and buildwin dirs (or *.dll and *.exe) entirely as they are not related in any way to the Linux part of things while creating the debian source package? We are just doing the same stuff Debian does here - hosting third party stuff in our code repository as a convenience to the package builder.

If it's a problem to throw it away, the licenses should be like this:
NSIS - zlib/libpng license
wx* dlls - wxwidgets license
vcredist_x86.exe - I don't know but as it's a redistributable, it should be legal to redistribute even though it comes from Microsoft.
The small dll's - They come from the NSIS community and are NSIS plugins, licensed zlib/libpng - Netsurfer should be able to tell you more I suppose.
opencpn_ui.exe - Also a question for Netsurfer, I suppose his product and actually the only thing we NEED to be hosting.

Pavel

[HamishB]

Originally Posted by nohal

Hamish,
Is there a problem just removing the wxWidgets and buildwin dirs (or *.dll and *.exe) entirely as they are not related in any way to the Linux part of things while creating the debian source package?

this is about what's in the source tarball, not the delivered binary package:

Originally Posted by hamish

Debian as-policy hosts a copy of the original tarball of each and every package they ship on the respective package page. One thing that falls out of that is that it's not enough for the packages they distribute to be free of any copyright liabilities thanks to the package build rules chopping stuff out; the organization also needs to legally protect itself from any undistributable stuff in the source tarballs too.

...

Originally Posted by nohal

We are just doing the same stuff Debian does here - hosting third party stuff in our code repository as a convenience to the package builder.

.. with the possible exception(?) being that Debian has strictly vetted all the 3rd party stuff it has let in. (thus here we are discussing this)

If it's a problem to throw it away, the licenses should be like this:
NSIS - zlib/libpng license
wx* dlls - wxwidgets license
vcredist_x86.exe - I don't know but as it's a redistributable, it should be legal to redistribute even though it comes from Microsoft.

For vcredist_x86 we'd really-really to verify that, guesses at what it should be are not good enough. I could not find any suitable legalese on the MS download page for it, redistributability is probably mentioned in the click-thru ..??

The small dll's - They come from the NSIS community and are NSIS plugins, licensed zlib/libpng - Netsurfer should be able to tell you more I suppose.

IIRC NSIS originally came from winamp/nullsoft and is completely free for us to use and redistribute.

I think the issue is more about separating the source code from the support programs into two different downloads.
Assuming all is legally proper, I don't know if that split is desired for OpenCPN or not, but it is worth talking about.

If the tarball is not reduced to source-code-only, and source-code-only is strictly demanded (I'm not sure it is), a solution for Debian may be a custom direct-from-git checkout of the source excluding the OSX and Windows build dirs. Then Debian's opencpn-$version.Orig.tar.gz consists of what's left.

opencpn_ui.exe - Also a question for Netsurfer, I suppose his product and actually the only thing we NEED to be hosting.

sorry for the dumb question, but what does opencpn_ui.exe do? How does it fit in? Is it the actual/final built program? If so, why is it distributed as part of the source code? (chicken vs egg)


thanks,
Hamish

[HamishB]

Hi,

another from the list of things needed for Debian but not sure if it's desired for mainline OpenCPN,

Debian asks to install plugin libraries to /usr/lib/opencpn-plugins/, but OpenCPN installs them to $shared_data_prefix/plugins/ (which expands to /usr/share/opencpn/plugins/).


I'm happy enough to keep on patching it, but thought I'd mention it.


thanks,
Hamish

[antonm]

Originally Posted by HamishB

one thing I hadn't noticed before Paul's latest review were the .exe and .dll binaries in the buildwin/ directory. Now, as part of their effort to adhere to

I think for now we just remove them out of .orig.tar.gz before submission, hope this will be suitable.

[antonm]

Another thing that I noted is that we need to change the versioning scheme. I am going to do that, looks like we will have to create changelog from scratch (anyway I think for debian submission we need to have it clean).

The versioning will be:

2.4~611 in order to allow us to have 2.4 release package (2.4 > 2.4~611). Any objections?

I have sent a question to mentors about stripping files out of orig.tar.gz since just tar --exclude confuses quilt that tried to record those changes in a patch.

Besides that this we do not have any lintian errors. Thus I will resubmit for another peer review as soon as I will figure out how to strip the tarball.

[bdbcat]

Antonm....

We do not plan a 2.4 Release.

When 2.4.xxx Beta program is done, the Release will be 2.5.yyyy

Next Beta program then is 2.6.zzz, leading to 2.7 Release, etc.

Dave

[antonm]

Originally Posted by bdbcat

When 2.4.xxx Beta program is done, the Release will be 2.5.yyyy
Next Beta program then is 2.6.zzz, leading to 2.7 Release, etc.

Ok. So the latest greatest 2.4.xxx will become 2.5 than following 2.5.xxx.
This means that we do not need ~ in package versions as I thought.

[bdbcat]

antonm...

Correct.
Dave

[HamishB]

Originally Posted by antonm

Besides that this we do not have any lintian errors. Thus I will resubmit for another peer review as soon as I will figure out how to strip the tarball.

Hi,

I just tried building on sid, we have 4 lintian errors. Three are template in copyright file for each of the 3 pkgs, should be an easy fix. the other one is complaining about embedded tinyxml.

I mean to reply to PaulW's last review item by item, please wait a couple days for me to do that before resubmitting, as it may answer some of their questions.


thanks,
Hamish

[antonm]

I mean to reply to PaulW's last review item by item, please wait a couple days for me to do that before resubmitting, as it may answer some of their questions.

Ok. I than taking on my behalf figuring out a way to produce a tarball with dlls removed. Looks easy from first sight, but the problem is that quilt assumes those removed items to be part of debian changes made to git tree and tries to create a patch for it. I asked help on mentors and got few suggestions that I need to try:

Stripping non-free/unnecessary files out of orig.tar.gz

In future we may consider migrating from quilt to a new experimental git-buildpackage tool since both opencpn upstream and allioth now using git.