OpenCPN Build on Debian

[HamishB]

Originally Posted by bdbcat

What is the code freeze date on Ubuntu 10.10? Maybe we can push ocpn V2.2 into that distribution? There are some meaningful changes and bug fixes to ocpn coming soon.

hmm, sorry I fed bad information. The freeze for Ubuntu 10.10 was actually a couple of weeks ago, the first beta came out yesterday:

Feature Freeze in place for Ubuntu 10.10 (Maverick Meerkat) | The Fridge

FWIW some months ago I applied for an exemption to get QGIS into 10.04 after the freeze but it wasn't accepted. In that case the package was already in Debian/testing which is further along than we are with OpenCPN. So I'm not too hopeful to get it in for 10.10. Oh well, we can still put it in the UbuntuGIS repo now though, I'll ping ubuntu(at)lists(dot)osgeo.org about what needs to be done for that.

https://wiki.ubuntu.com/UbuntuGIS

by building 2.1.624a-Source.tgz in a clean Unbuntu 10.04 VM with the current debiangis/ build files I could successfully make the amd64 package and then install and run it on another 10.04 amd64 ubuntu which does have the problematic non-Free nvidia drivers installed.

the only lintian warning reported on the package is: "desktop-entry-contains-deprecated-key usr/share/applications/opencpn.desktop:15 TerminalOptions".

It seems that Anton's debian/patches/desktop-entry-spec.patch already addresses this, but the patch is not being applied for some reason.


Hamish

[HamishB]

fyi, debiangis build files:

[pkg-grass] Index of /packages/opencpn

[bdbcat]

Hamish

"It seems that Anton's debian/patches/desktop-entry-spec.patch already addresses this, but the patch is not being applied for some reason."

Where is this patch? I guess I missed it somehow.

I'll get it in ASAP.

Dave

[HamishB]

Originally Posted by bdbcat

Where is this patch? I guess I missed it somehow.

* [pkg-grass] Index of /packages/opencpn/trunk/debian/patches

* https://sourceforge.net/tracker/?fun...42&atid=894806

I'll get it in ASAP.

thanks,

Hamish

[HamishB]

Originally Posted by HamishB

"It seems that Anton's debian/patches/desktop-entry-spec.patch already addresses this, but the patch is not being applied for some reason."

(by that I meant it is not being applied within the debian packaging scripts for some reason, not that it hadn't been applied upstream yet; but that too :-) )

[HamishB]

Hi,

In the DebianGIS svn I've removed the build dep on the (dying?) imagemagick pkg (opencpn.xmp is already supplied, no need to remake it), and added a dependency for dpatch, but I'm not enough of a dpkg rules/Makefile guru to know the best way to enable pushing the patches through `quilt`.

[pkg-grass] Index of /packages/opencpn/trunk/debian


Hamish

[HamishB]

Hi,

just an update on the latest 2.1.624a tarball + Anton's DebianGIS svn build rules:

* dpatch still isn't working, some hints here:
Gmane Loom

* lintian check gives a few wishlist items (one fixed as soon as patches are working)

ubuntu_lucid$ lintian --info --display-info --display-experimental --pedantic \
   --show-overrides --checksums --color auto opencpn_2.1.624a-1_amd64.deb

I: opencpn: arch-dep-package-has-big-usr-share 24309kB 89%
N: 
N:    The package has a significant amount of architecture-independent data
N:    (over 4MB, or over 2MB and more than 50% of the package) in /usr/share
N:    but is an architecture-dependent package. This is wasteful of mirror
N:    space and bandwidth since it means distributing multiple copies of this
N:    data, one for each architecture.
N:    
N:    If the data in /usr/share is not architecture-independent, this is a
N:    Policy violation that should be fixed by moving the data elsewhere
N:    (usually /usr/lib).
N:    
N:    Refer to Debian Developer's Reference section 6.7.5
N:    (Architecture-independent data) for details.
N:    
N:    Severity: wishlist, Certainty: certain
N: 

I: opencpn: possible-documentation-but-no-doc-base-registration
N: 
N:    The package ships a .html or .pdf file under /usr/share/doc/, which are
N:    usually documentation, but it does not register anything in doc-base.
N:    (Files under an examples directory are excluded.)
N:    
N:    Refer to Debian Policy Manual section 9.10 (Registering Documents using
N:    doc-base) for details.
N:    
N:    Severity: wishlist, Certainty: possible
N: 

P: opencpn: no-upstream-changelog
N: 
N:    The package does not install an upstream changelog file. If upstream
N:    provides a changelog, it should be accessible as
N:    /usr/share/doc/<pkg>/changelog.gz.
N:    
N:    It's currently unclear how best to handle multiple binary packages from
N:    the same source. Some maintainers put a copy of the upstream changelog
N:    in each package, but it can be quite long. Some include it in one
N:    package and add symlinks to the other packages, but this requires there
N:    be dependencies between the packages. Some only include it in a
N:    "central" binary package and omit it from more ancillary packages.
N:    
N:    Refer to Debian Policy Manual section 12.7 (Changelog files) for
N:    details.
N:    
N:    Severity: pedantic, Certainty: wild-guess
N: 

I: opencpn: desktop-entry-contains-encoding-key /usr/share/applications/opencpn.desktop:4 Encoding
N: 
N:    The Encoding key is now deprecated by the FreeDesktop standard and all
N:    strings are required to be encoded in UTF-8. This desktop entry
N:    explicitly specifies an Encoding of UTF-8, which is harmless but no
N:    longer necessary.
N:    
N:    The desktop-file-validate took in the desktop-file-utils package is
N:    useful for checking the syntax of desktop entries.
N:    
N:    Refer to
N:    http://standards.freedesktop.org/desktop-entry-spec/1.0/apc.html for
N:    details.
N:    
N:    Severity: wishlist, Certainty: certain
N: 

W: opencpn: desktop-entry-contains-deprecated-key usr/share/applications/opencpn.desktop:15 TerminalOptions
N: 
N:    The key on this line of the desktop entry has been deprecated in the
N:    FreeDesktop specification.
N:    
N:    The desktop-file-validate took in the desktop-file-utils package is
N:    useful for checking the syntax of desktop entries.
N:    
N:    Refer to
N:    http://standards.freedesktop.org/desktop-entry-spec/1.0/apc.html for
N:    details.
N:    
N:    Severity: normal, Certainty: certain
N:

Hamish

[antonm]

Originally Posted by HamishB

* dpatch still isn't working, some hints here:
Gmane Loom

Hi. I am a kind of back here. I am not sure if we can use dpatch and quilt the same time. I used quilt in initial package as the most top notch way and the patches are handled automatically by debian packaging scripts.

Maybe I can check and try applying patches via quilt?

[HamishB]

Originally Posted by antonm

Hi. I am a kind of back here. I am not sure if we can use dpatch and quilt the same time. I used quilt in initial package as the most top notch way and the patches are handled automatically by debian packaging scripts.

Maybe I can check and try applying patches via quilt?

yeah, my dpatch attempt should be backed out. Paul has some suggestions on what to do with that in the latest DebianGIS thread:

> "Please use dpkg-source v3 instead of dpatch."

probably more important is to rely on the existing xtide-data package(s) for the 7mb harmonics files, and move 6mb docs into a opencpn-doc package. (will try to crunch those .png images, see if there's any space to be saved that way [optipng, advpng, or pngcrush, and reducing color palette # of colors if possible])


cheers,
Hamish

[antonm]

Originally Posted by HamishB

yeah, my dpatch attempt should be backed out. Paul has some suggestions on what to do with that in the latest DebianGIS thread:

> "Please use dpkg-source v3 instead of dpatch."

Yup, that is how it is right now, check /packages/opencpn/trunk/debian/source/format it says "3.0 (quilt)", maybe that is why your dpatch attaempt failed as it still says that quilt is used for patches.

I will have a look on why desktop patch is not applied and will back out dpatch then. Ideally for Dave is to include the corrected desktop file into the source, it is a minor change that does not break anything.

probably more important is to rely on the existing xtide-data package(s) for the 7mb harmonics files, and move 6mb docs into a opencpn-doc package.

Yup, indeed the data separation is the most hot topic and action item for the package. Can we directly use tides data from xtide-data or some post processing is needed? I will have a look in OpenCPN sources on how to pass the harmonics data files path to it.

[HamishB]

dpatch is now backed out.

The ubuntu 10.04 xtide harmonics packages (incl non-free addon) --- & so I assume debian versions of the same --- do not include the source raw ascii HARMONICS file, just the processed .tcd binary version of it. So we're not technically duplicating that.

Annoyingly they've bulk removed from the debian xtide-data package anything they weren't sure of the heritage of without checking the per-station header comment which in many cases explicitly release the data to the public domain. which pretty much means that only the NOAA stations remain. Some time ago I recalculated a few of the local New Zealand stations which were far out; somewhere I'll have my code for that job but I'm not looking forward to having to redo every station in the country and fighting to get them back in. more work...

I can have a go trying to generalize [Douglas-Peucker or some other alg..] the NaturalEarth.org vector coastlines to something smaller/better quality than the included WVS data, but I'm not really confident that I'll be able to get it smaller+better than their tiny 6mb.

I have more confidence about being able to losslessly optimize the .png images in the help docs to a smaller size.


none of these things are blockers IMO though, just optimizations.


Hamish

[antonm]

Originally Posted by HamishB

dpatch is now backed out.

I have updated "debian" directory to work with the latest sources in git. Desktop file patch is not needed anymore as it is applied upstream, so I emptied the patch directory for now.

The package builds fine, but we have a new blocker now:

E: opencpn: arch-dependent-file-in-usr-share ./usr/share/opencpn/plugins/libcelestial_navigation_pi.so
E: opencpn: arch-dependent-file-in-usr-share ./usr/share/opencpn/plugins/libdashboard_pi.so
E: opencpn: arch-dependent-file-in-usr-share ./usr/share/opencpn/plugins/libgrib_pi.so
E: opencpn: embedded-library ./usr/share/opencpn/plugins/libgrib_pi.so: bzip2

According to FHS

Filesystem Hierarchy Standard

/usr/share is for the Architecture-independent data, and thus we should not put binary libraries there.

I think, the proper place for them will be in /usr/lib/opencpn/plugins

Will patch it.

[antonm]

Originally Posted by HamishB

assume debian versions of the same --- do not include the source raw ascii HARMONICS file, just the processed .tcd binary version of it. So we're not technically duplicating that.

I can have a go trying to generalize [Douglas-Peucker or some other alg..] the NaturalEarth.org vector coastlines to something smaller/better quality than the included WVS data, but I'm not really confident that I'll be able to get it smaller+better than their tiny 6mb.

I started threads about those issues on pkg-grass-general list:

[DebianGIS] Packaging of World Vector Shoreline (WVS) data
[DebianGIS] Approaches to Harmonics Files Packaging

I think we will be able to come with approaches there.

[HamishB]

Originally Posted by antonm

I have updated "debian" directory to work with the latest sources in git.

fwiw for other projects we have maintained the latest release packaging rules in trunk (i.e. always sid-ready) and worked on new developments in a branch, but in this case a new release is imminent(?) and we are still enough in the initial packaging development phase that I don't think it matters too much. (yet)

Desktop file patch is not needed anymore as it is applied upstream, so I emptied the patch directory for now.

The package builds fine,

great, thanks

but we have a new blocker now:

E: opencpn: arch-dependent-file-in-usr-share ./usr/share/opencpn/plugins/libcelestial_navigation_pi.so
E: opencpn: arch-dependent-file-in-usr-share ./usr/share/opencpn/plugins/libdashboard_pi.so
E: opencpn: arch-dependent-file-in-usr-share ./usr/share/opencpn/plugins/libgrib_pi.so
E: opencpn: embedded-library ./usr/share/opencpn/plugins/libgrib_pi.so: bzip2

According to FHS

Filesystem Hierarchy Standard

/usr/share is for the Architecture-independent data, and thus we should not put binary libraries there.

I think, the proper place for them will be in /usr/lib/opencpn/plugins

Will patch it.

right, /usr/lib/opencpn/plugins looks like the right place for it. (see for example gdal)


Hamish

[antonm]

Originally Posted by HamishB

fwiw for other projects we have maintained the latest release packaging rules in trunk (i.e. always sid-ready) and worked on new developments in a branch, but in this case a new release is imminent(?) and we are still enough in the initial packaging development phase that I don't think it matters too much. (yet)

Yup. When I did submit to trunk I considered that there may be probably more than one release before we will go into the main. I prefer to commit often, so from other side it may be necessary to produce a development branch already.

There is another thing that I am thinking about that need to be defined till the official inclusion. It is a versioning scheme. Currently I used 2.2.918 for the current git version (2.2 is major and minor version and 918 is patch version from VERSION.cmake). It is ok, since it is greater than previous package 2.1.624a and thus it will upgrade. However when we have release the version will be 2.2 as seen to the users, but that is less than 2.2.918 and thus it will not upgrade.

The two options is to always specify patch versions and the release version will be some 2.2.XXX where XXX > 918, or the other way that is probably less confusing to users is to have it named as 2.2 version. This means that 2.2.918 should never go in its current form and I need to figure out better way of package versioning that will support both official releases in the way clear for users and some way to packaging git versions when needed.