Debian Bug report logs - #538067
ITP: opencpn -- A Chartplotter and GPS Navigation Software (written by and for sailors)

Package: wnpp; Maintainer for wnpp is wnpp@debian.org;

Reported by: Anton Martchukov <anton@martchukov.com>

Date: Wed, 22 Jul 2009 20:18:02 UTC

Owned by: Anton Martchukov <anton@martchukov.com>

Severity: wishlist

Merged with 653601

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org, <wnpp@debian.org>:
Bug#538067; Package wnpp. (Wed, 22 Jul 2009 20:18:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Anton Martchukov <anton@martchukov.com>:
New Bug report received and forwarded. Copy sent to debian-devel@lists.debian.org, <wnpp@debian.org>. (Wed, 22 Jul 2009 20:18:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Anton Martchukov <anton@martchukov.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: ITP: opencpn -- A concise ChartPlotter/Navigator
Date: Thu, 23 Jul 2009 00:15:13 +0400
Package: wnpp
Severity: wishlist
Owner: Anton Martchukov <anton@martchukov.com>

* Package name    : opencpn
  Version         : 1.3.2
  Upstream Author : David Register <bdbcat@yahoo.com>
* URL             : http://opencpn.sourceforge.net/
* License         : GPL
  Programming Lang: C/C++
  Description     : A concise ChartPlotter/Navigator

A cross-platform ship-borne GUI application supporting 

    * GPS/GPDS Postition Input 
    * BSB Raster Chart Display
    * S57 Vector ENChart Display
    * AIS Input Decoding
    * Waypoint Autopilot Navigation




Information forwarded to debian-bugs-dist@lists.debian.org, <wnpp@debian.org>:
Bug#538067; Package wnpp. (Tue, 20 Oct 2009 22:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Anton Martchukov <anton@martchukov.com>:
Extra info received and forwarded to list. Copy sent to <wnpp@debian.org>. (Tue, 20 Oct 2009 22:15:03 GMT) Full text and rfc822 format available.

Message #10 received at 538067@bugs.debian.org (full text, mbox):

From: Anton Martchukov <anton@martchukov.com>
To: 538067@bugs.debian.org
Subject: Blocked by wxGTK #549770
Date: Wed, 21 Oct 2009 01:49:32 +0400
[Message part 1 (text/plain, inline)]
Alas I am not able to build OpenCPN using wxGTK version in
Debian with the blocker #549770 bug.

The bug looks to be fixed upstream, but wxWidgets2.8 is orphaned
as of now #539170.

Have to wait for any changes or progress.

-- 
Anton Martchukov                     http://www.martchukov.com
0xFC4FBF28  96BC 3DAB 231A 7FCC 4F49  D783 9A69 65C1 FC4F BF28
[signature.asc (application/pgp-signature, inline)]

Added blocking bug(s) of 538067: 568006 Request was from Anton Martchukov <anton@martchukov.com> to control@bugs.debian.org. (Mon, 01 Feb 2010 20:36:02 GMT) Full text and rfc822 format available.

Removed blocking bug(s) of 538067: 568006 Request was from Anton Martchukov <anton@martchukov.com> to control@bugs.debian.org. (Tue, 02 Feb 2010 21:42:13 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, <wnpp@debian.org>:
Bug#538067; Package wnpp. (Sun, 07 Feb 2010 21:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Anton Martchukov <anton@martchukov.com>:
Extra info received and forwarded to list. Copy sent to <wnpp@debian.org>. (Sun, 07 Feb 2010 21:03:06 GMT) Full text and rfc822 format available.

Message #19 received at 538067@bugs.debian.org (full text, mbox):

From: Anton Martchukov <anton@martchukov.com>
To: 538067@bugs.debian.org
Subject: Package Available to Test
Date: Sun, 7 Feb 2010 23:49:45 +0300
[Message part 1 (text/plain, inline)]
I created the package that is now available for testing
under my repository.

Add

deb     http://debian.martchukov.com/apt  sid main contrib non-free
deb-src http://debian.martchukov.com/apt  sid main contrib non-free

to /etc/apt/sources.list, do aptitude update and then use

aptitude install opencpn to install package and
apt-get source opencpn to grab sources

Now I'll look for a mentor to upload package.

-- 
Anton Martchukov                     http://www.martchukov.com
0xFC4FBF28  96BC 3DAB 231A 7FCC 4F49  D783 9A69 65C1 FC4F BF28
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Tue, 21 Sep 2010 09:51:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Tue, 21 Sep 2010 09:51:09 GMT) Full text and rfc822 format available.

Message #24 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: 538067@bugs.debian.org
Subject: OpenCPN packaging updates
Date: Tue, 21 Sep 2010 21:31:32 +1200
Hi,

some email threads discussing progress--

packaging files now maintained in DebianGIS's Alioth svn repo:
 http://svn.debian.org/viewsvn/pkg-grass/packages/opencpn/trunk/debian/


debian threads:
 http://thread.gmane.org/gmane.comp.gis.grass.pkg.general/3435/
 http://lists.debian.org/debian-mentors/2010/02/msg00115.html
 http://lists.debian.org/debian-mentors/2010/02/threads.html#00098


upstream thread:
 http://www.cruisersforum.com/forums/f134/opencpn-build-on-debian-35977-7.html



cheers,
Hamish




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Fri, 15 Apr 2011 12:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Fri, 15 Apr 2011 12:30:04 GMT) Full text and rfc822 format available.

Message #29 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: DebianGIS <debian-gis@lists.debian.org>
Cc: 538067@bugs.debian.org
Subject: Re: ITP: opencpn -- A concise ChartPlotter/Navigator
Date: Sat, 16 Apr 2011 00:05:33 +1200
Hi,

some time has passed so I thought I'd take another stab at this one:
  http://svn.debian.org/viewsvn/pkg-grass/packages/opencpn/trunk/debian/

It's in pretty good shape now, one lintian error remains, and one
big todo.

The program has enjoyed phenomenal growth in popularity for a niche
product, ~400 downloads per day:
http://sourceforge.net/project/stats/detail.php?group_id=180842&ugn=opencpn&type=prdownload&mode=alltime&file_id=0

That success is well deserved! It's a fine program.

packaging efforts documented here:
  http://www.cruisersforum.com/forums/f134/opencpn-build-on-debian-35977-8.html#post667237




lintian
=======
 E: opencpn: embedded-library ./usr/share/opencpn/plugins/libgrib_pi.so: bzip2

I've prepared the following patch:
"""
+++ opencpn/plugins/grib_pi/CMakeLists.txt      2011-04-15 15:18:35.165862744 +1200
@@ -79,18 +79,18 @@
             src/GribRecord.cpp  
             src/zuFile.cpp 
             src/IsoLine.cpp 
-            src/bzip2/bzlib.c 
-            src/bzip2/blocksort.c 
-            src/bzip2/compress.c 
-            src/bzip2/crctable.c 
-            src/bzip2/decompress.c 
-            src/bzip2/huffman.c 
-            src/bzip2/randtable.c
+#            src/bzip2/bzlib.c 
+#            src/bzip2/blocksort.c 
+#            src/bzip2/compress.c 
+#            src/bzip2/crctable.c 
+#            src/bzip2/decompress.c 
+#            src/bzip2/huffman.c 
+#            src/bzip2/randtable.c
        )
 ADD_LIBRARY(${PACKAGE_NAME} SHARED ${SRC_GRIB})
 
-INCLUDE_DIRECTORIES(${PLUGIN_SOURCE_DIR}/src/zlib-1.2.3)
-INCLUDE_DIRECTORIES(${PLUGIN_SOURCE_DIR}/src/bzip2)
+#INCLUDE_DIRECTORIES(${PLUGIN_SOURCE_DIR}/src/zlib-1.2.3)
+#INCLUDE_DIRECTORIES(${PLUGIN_SOURCE_DIR}/src/bzip2)
 
 IF(WIN32)
   SET(OPENCPN_IMPORT_LIB "../../${CMAKE_CFG_INTDIR}/${PARENT}")
"""

and it builds, but at run-time the plugin fails with this error message in ~/opencpn.log:
"""
15:25:21: PlugInManager searching for PlugIns in location /usr/lib/opencpn-plugins
15:25:21: PlugInManager: Loading PlugIn: /usr/lib/opencpn-plugins/libgrib_pi.so
15:25:21: Error: /usr/lib/opencpn-plugins/libgrib_pi.so: undefined symbol: BZ2_bzReadClose
15:25:21:    PlugInManager: Cannot load library: /usr/lib/opencpn-plugins/libgrib_pi.so
"""

the Build-depends in debian/control does contain libbz2-dev (which supplies libbz2.a) but I'm missing how to link against that in the
above CMakeLists.txt file. (I'm no cmake expert)

any ideas?


todo
====
I think a necessary hurdle to overcome is to donate some code to allow OpenCPN to read from the GMT flavour of the GSHHS world coastline data, so that they (and ZyGrib, and other packages which use that coastline data) can all share the common data packages.

The .deb is 16mb right now, which I don't think is a blocker for upload.
It would be nice to get the half-dozen or so packages which are all
shipping the variants of the same world-coastline to use the same gmt-
coastline data packages though. (see earlier emails in this ML's archive
for details)


thanks,
Hamish




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sun, 01 May 2011 01:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sun, 01 May 2011 01:27:06 GMT) Full text and rfc822 format available.

Message #34 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>
Cc: Anton Martchukov <anton@martchukov.com>, Paul Wise <pabs@debian.org>, David S Register <bdbcat@yahoo.com>, 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Sat, 30 Apr 2011 18:22:23 -0700 (PDT)
Hi,

this is an update on this from a year ago:
   http://lists.debian.org/debian-mentors/2010/02/msg00115.html

after a while and a fair bit of work upstream* I think we're ready for
another shot at review.  *[mainly hard work by Anton and Dave]

In the last year the program has enjoyed phenomenal growth in popularity
for a niche product, now ~400 downloads per day from sourceforge:
http://sourceforge.net/project/stats/detail.php?group_id=180842&ugn=opencpn&type=prdownload&mode=alltime&file_id=0

That success is well deserved! It's a fine program.

packaging efforts are being coordinated here:
  http://www.cruisersforum.com/forums/f134/opencpn-build-on-debian-35977-8.html#post667237


Highlights since last time:
- copyright review conducted upstream
- upstream now uses Git, source tree cleaned up
- arch-independent -data and -doc split off
- depends on xtide's coastline package instead of shipping a dupe
- a lot of patches based on the last review now applied upstream


debian/ dir can be viewed here:
  http://svn.debian.org/viewsvn/pkg-grass/packages/opencpn/trunk/debian/


to play along at home:
  git clone git://opencpn.git.sourceforge.net/gitroot/opencpn/opencpn
  svn co svn://svn.debian.org/pkg-grass/packages/opencpn/trunk/debian opencpn/debian
  cd opencpn/
  #review+install any build depends ...
  grep -A1 'Build-Depends:' debian/control
  # ...
  debuild -i -uc -us -b


I've done my package building on Squeeze. Maybe package deps have
changed in sid, maybe not? I haven't set up a sid chroot or VM on
my new machine yet. I mention this as some gtk issues have been
reported on Ubu 11.04 in the last days and are currently being
diagnosed.


To address Paul's earlier comments:

--

> On Mon, Feb 8, 2010 at 4:06 PM, Paul Wise <pabs@debian.org> wrote:
> 
> > I'll take a closer look at the package when I'm on a Debian system.
> 
> I took a much closer look at the package and in summary; I'd really
> like to sponsor this package but it needs a lot of work upstream,
> especially in the copyright/license department. Please do contact this
> list again when you have worked with upstream to resolve the issues
> listed below. Should you have further questions, please don't hesitate
> to contact this list.

... and so here we are

> I think upstream is installing the icons in the wrong directory. IIRC
> it should be be installed as
> /usr/share/icons/hicolor/48x48/apps/opencpn.png for bitmaps of size 48
> x 48. XPM is not a good format for modern desktops since it has only
> 1-bit transparency and therefore no possibility of anti-aliased
> transparency. Unfortunately the Debian menu system requires it. I'd
> suggest that the .xpm file be installed in /usr/share/pixmaps, IIRC
> that has a lower priority in most desktops than /usr/share/icons/.
> Also, one of the opencpn.svg files could be shipped as
> /usr/share/icons/hicolor/scalable/apps/opencpn.svg

done upstream.

> The file 136ReleaseNotes might be relevant to install, in
> /usr/share/doc/opencpn perhaps. Hmm, half of it seems to be exactly
> the same as the changelog so maybe not. I suggest contacting upstream
> about it. Looks like upstream is using the ChangeLog as a NEWS file
> but have abandoned the NEWS file after the 1.2.6 release and now store
> NEWS entries in the ChangeLog instead. Whee! The NEWS file should
> summarise user-visible changes between releases and the ChangeLog file
> should be similar to VCS logs. The GNU Coding Standards document has
> more detail here:
> 
> http://www.gnu.org/prep/standards/standards.html#NEWS-File
> http://www.gnu.org/prep/standards/standards.html#Change-Logs

cleaned up/out upstream.

> I'm confused, is upstream using both autotools and CMake?

now it's cmake.

> 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. Same for
> src/grib.  All 3 are already in Debian:
> 
> http://packages.debian.org/zygrib
> http://packages.debian.org/zlib
> http://packages.debian.org/bzip2
> 
> src/mygdal, src/myiso8211, src/nmea0183 all look like embedded code
> copies too. 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. warzone2100 does
> this and it seems to work well.

You guessed well; bzip2 and zlib are there for the MS Windows port [Grib
plugin]. The cmake rules are patched to use the system's zlib, bzip2 if
UNIX. It is expected this patch will be applied upstream in the near
future. Released tarballs are actively targeted at Linux, Mac OSX,
and MS Windows builds; I am not going to ask upstream to issue a
special stripped down version of the tarball every release just for us,
or maintain such a thing myself. If there was some sort of license
issue I would, but for the sake of an unused 200kb(uncompressed) in
the .orig.tar.gz, it just ain't worth the effort.

Grib code has been moved to a plugin. ZyGrib does not supply a lib
package, nor even use libaries within its main package- it's a stand
alone binary. So OpenCPN clone some of their reader code. It is beyond
the scope of this packaging effort to refactor a 3rd party's application.
(aside: I suspect their debian packaging needs a little work too)

So far just two plugins ship with the code. It is expected that more
will come along (see the opencpn download page for some works in
progress), and when that happens we will most likely split them out
into their own binary package. But for now it's not worth the effort.


As for src/mygdal and src/myiso8211, GDAL does supply nice library
packages but OpenCPN has modified and adapted them. Dave (the OpenCPN
lead author) had this to say when asked:

Dave wrote:
> > 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


As for src/nmea0183, AFAIK it does not exist in library form elsewhere
in Debian, and if copyright+Author header comments are anything to go
by has been specifically tailored/reworked by the OpenCPN lead dev.


> src/nmea0183 has no copyright information and this as a license:
> 
> You can use it any way you like.
> 
> Unfortunately this does not give Debian permission to copy, modify or
> distribute.

AFAIU the original author was contacted by upstream, the reply was
 "It is BSD license, do with it what you will"
which is now given in the header comments there.


> Another embedded code copy, Stackwalker.cpp, probably could be
> replaced by valgrind.

AFAICT that's no longer in the source tree.

> bbox.cpp looks like it was copied from a really old version of wxWidgets;
>
> http://wxwindows2.4.sourcearchive.com/documentation/2.4.4.1.1ubuntu2/bbox_8cpp-source.html
> 
> Surely newer versions of wxWidgets contain similar functionality that
> could be used instead of this code copy. There are other files that
> look like they are similar; inpcons.h dymemdc.h inphand.h uniparts.h
> and anything containing the phrase "Purpose:  Optimized".

This one I haven't looked into very hard. Only that bbox.cpp seems
like a pretty minimal bit of code, and I'm aware that between now and
the next stable release one main set of changes planned is to rewrite
some of the windowing/toolbar code.
aka waiting for the dust to settle before worrying about that too much.


> The OpenCPN code contains this template:
> 
>  *   Copyright (C) $YEAR$ by $AUTHOR$   *
>  *   $EMAIL$   *
> 
> Upstream really needs to replace these by real information. Some files
> have the right info but still have the template.

AFAICT $AUTHOR$+$YEAR$ fixed upstream. Some $EMAIL$ remain. I've filed
that as a low-priority bug upstream, but as email is not a required part
of the copyright I don't think it's a blocker for this packaging effort,
and will be fixed in due course.


> BTW, the template is wrong since (C) is not a valid symbol for
> copyright, IIRC only "Copyright", "Copyr." and "©" are.

"Copyright" is there, which is enough to get the job done. I'll leave
the fight about copyright symbols to others; just to note AFAIK in the
history of copyright law no one has ever had the chutzpah to try and
claim invalid copyright based on that in front of a judge.


> src/georef.c has this non-free license (non-commercial use/etc is non-free):
> 
> /* Permission  to use, copy,  modify, and distribute  this software and its */
> /* documentation for non-commercial purpose, is hereby granted without fee, */
> /* providing that the  copyright notice  appear in all copies and that both */
> /* the  copyright notice and  this permission  notice appear in  supporting */
> /* documentation.  I make no representations about  the suitability of this */
> /* software  for any  purpose.  It is  provides "as is" without  express or */
> /* implid warranty.                                                         */
> 
> Similar for gpc.h georef.h

AFAIU the original author was contacted here as well, and the headers
have been updated accordingly.
gpc.h no longer exists.


> macsercomm.cpp looks slightly suspect. I'd like to know its lineage,
> copyright and license. Same for macutils.c 

src/about.cpp lists seriallib as being GPL.
We can request better header comments.

> routeprop.cpp

author/copyright now added (written by the opencpn lead dev)

> scrollingdialog.cpp
> scrollingdialog.h

now listed as wxWindows licence (LGPL)

> sercomm.cpp macsercomm.h macutils.h
> sercomm.h

I expect it's from serialib & so GPL; see above.

> routeprop.h tcmgr.h 

author/copyright now added (written by the opencpn lead dev)

> triangulate.h

author/copyright now added (public domain)

> data/s57data/*

author/copyright now added: from Sylvain Duclos's libS52 (GPL)
libS52 can be found in the the contrib section of the OpenEV
cvs repo at SourceForge. (years ago openev was the semi-reference
data viewer for GDAL)

> data/sounds/alarm2.wav contain these comments:
> 
> Copyright . Cinematronics 1995
> Microsoft Plus! . for Windows 95
> 
> It is highly likely that it is non-free, and I'd wager that alarm1.wav is too.

replaced by new from-scratch versions. see /usr/share/doc/opencpn-data/README.bells.

> The source code for HARMONIC.IDX does not seem to be distributed in
> the package. It says "This file is automatically generated by
> Tide2idx", so source code should exist.

The version opencpn ships is an ASCII text file.


Here's the contents of /usr/share/doc/opencpn-data/README.harmonics:
===========================
The opencpn-data package currently ships the ASCII version of xtide's
tidal harmonics tables, while the xtide-data package ships a binary-
blob version.


The tide and current harmonic data contained herein are derived from the
corresponding XTIDE harmonic data. The file data have been tweaked to
work nicely in the US, especially fixing current direction reporting. We
have also added additional global tide stations, and corrected calculation/
display units where sensible. A generic XTIDE harmonic file set will be
functional, but less useful than the harmonic data packaged with OpenCPN.


On 21 Apr 2011, Dave (bdbcat) wrote:
"""
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.
...
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.
"""
===========================

> data/wvsdata/ is claimed to be open source, but is a subset. I'd
> suggest that it be packaged separately since it is from wxTide. It is
> also in a binary format so I wonder how it is supposed to be edited or
> what the source code really is.

wvsdata (world vector shoreline) has now been dropped from the opencpn .deb
in favour of recommending the version supplied by the existing
xtide-coastline package.  afaik the data format is published publicly.

Convincing OpenCPN, Xtide, ZyGrib, and GMT, ..? to all consolidate on the
same world vector coastline data remains a TODO (I'd humbly suggest
focusing on GMT's version(s) of GSHHS as the standard), but remains beyond
the scope of this [OpenCPN] packaging effort.


> debian/copyright needs to document all the licenses and copyright
> information. You may also want to consider DEP5 (Machine-readable
> debian/copyright):
> 
> http://dep.debian.net/deps/dep5/

see latest version of debian/copyright, and also have a look in
src/about.cpp. Probably more could be done here, although it is
unclear to me exactly what is needed where.

> Unfortunately source.debian.net is down otherwise I'd try to find
> other packages containing some of the above files.
> 
> opencp.cpp is empty, weird.

no longer exists?

> Normally, .mo files wouldn't be distributed in the source package.

now only .po are shipped.


> lintian complaints not mentioned:
> 
> I: opencpn: arch-dep-package-has-big-usr-share 16884kB 88%
> I: opencpn: desktop-entry-contains-encoding-key
> /usr/share/applications/opencpn.desktop:4 Encoding
> I: opencpn: possible-documentation-but-no-doc-base-registration

the package is now lintian clean on squeeze.


> dpkg-shlibdeps warnings. Some of these are possibly issues in
> wxWidgets so you may not be able to do anything about them short of
> filing a bug.
> 
> dpkg-shlibdeps: warning: dependency on libwx_gtk2u_richtext-2.8.so.0
> could be avoided if "debian/opencpn/usr/bin/opencpn" were not
> uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libwx_gtk2u_html-2.8.so.0 could
> be avoided if "debian/opencpn/usr/bin/opencpn" were not uselessly
> linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libwx_gtk2u_aui-2.8.so.0 could
> be avoided if "debian/opencpn/usr/bin/opencpn" were not uselessly
> linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libwx_gtk2u_xrc-2.8.so.0 could
> be avoided if "debian/opencpn/usr/bin/opencpn" were not uselessly
> linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libwx_gtk2u_qa-2.8.so.0 could
> be avoided if "debian/opencpn/usr/bin/opencpn" were not uselessly
> linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libGL.so.1 could be avoided if
> "debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
> (they use none of its symbols).

I have not looked at those, nor know how they could be addressed.


> Some gcc warnings you might want to investigate and forward upstream,
> patches preferred of course :)
> 
> In file included from src/chart1.cpp:266:
> ././include/grib.h:83: warning: 'typedef' was ignored in this declaration
> src/cutil.c:106: warning: 'cvsid_aw' defined but not used
> src/georef.c:59: warning: 'cvsid_aw' defined but not used
> src/cm93.cpp: In member function 'bool
> cm93compchart::RenderNextSmallerCellOutlines(wxDC*, ViewPort&, bool)':
> src/cm93.cpp:4581: warning: suggest parentheses around '&&' within '||'
> src/s57chart.cpp: In member function 'void
> s57chart::CreateSENCRecord(OGRFeature*, FILE*, int, S57Reader*)':
> src/s57chart.cpp:4746: warning: format '%d' expects type 'int', but
> argument 3 has type 'size_t'
> src/tri.c:125: warning: 'cvsid_aw' defined but not used
> src/myiso8211/ddfrecord.cpp: In member function 'int DDFRecord::Write()':
> src/myiso8211/ddfrecord.cpp:285: warning: format '%05d' expects type
> 'int', but argument 3 has type 'size_t'
> src/myiso8211/ddfrecord.cpp:289: warning: format '%05d' expects type
> 'int', but argument 3 has type 'size_t'

I have not attempted to review or address compiler warnings, but note that
the code has changed significantly since the above, so best to look at a
fresh build.


> Upstream is using CVS, you might want to consider suggesting that they
> switch to a more modern VCS like git, bzr or SVN.

A matter of personal preference IMO, but upstream has now switched to git.


> In addition, I found some spam on the upstream website:
> 
> http://opencpn.org/node/67
> http://opencpn.org/node/73
> http://opencpn.org/node/72
> http://opencpn.org/node/69
> http://opencpn.org/node/65
> http://opencpn.org/node/68
> 
> Some former spam pages still show up in menus:
> 
> http://opencpn.org/node/70
> http://opencpn.org/node/71
> http://opencpn.org/node/66

long gone.

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

Xtide is already packaged (AFAIK wxTide is a Windows port of it).
CapCode is alive!  http://sourceforge.net/apps/trac/capcode/timeline


regards,
Hamish





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Mon, 02 May 2011 01:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Mon, 02 May 2011 01:51:03 GMT) Full text and rfc822 format available.

Message #39 received at 538067@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>, 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Mon, 2 May 2011 09:47:36 +0800
On Sun, May 1, 2011 at 9:22 AM, Hamish <hamish_b@yahoo.com> wrote:

> this is an update on this from a year ago:
>   http://lists.debian.org/debian-mentors/2010/02/msg00115.html
>
> after a while and a fair bit of work upstream* I think we're ready for
> another shot at review.  *[mainly hard work by Anton and Dave]

Firstly, I have to thank both of them for their persistence and hard
work! Much appreciated.

> I've done my package building on Squeeze. Maybe package deps have
> changed in sid, maybe not? I haven't set up a sid chroot or VM on
> my new machine yet. I mention this as some gtk issues have been
> reported on Ubu 11.04 in the last days and are currently being
> diagnosed.

Generally one should build and test using the suite you are uploading
to. Most uploads go to sid so they should be built and tested there.

> You guessed well; bzip2 and zlib are there for the MS Windows port [Grib
> plugin]. The cmake rules are patched to use the system's zlib, bzip2 if
> UNIX. It is expected this patch will be applied upstream in the near
> future. Released tarballs are actively targeted at Linux, Mac OSX,
> and MS Windows builds; I am not going to ask upstream to issue a
> special stripped down version of the tarball every release just for us,
> or maintain such a thing myself. If there was some sort of license
> issue I would, but for the sake of an unused 200kb(uncompressed) in
> the .orig.tar.gz, it just ain't worth the effort.

Fair enough. Please remove the embedded code copies before
debian/rules build (or configure) so that the Debian package can never
build against it by accident.

> Grib code has been moved to a plugin. ZyGrib does not supply a lib
> package, nor even use libaries within its main package- it's a stand
> alone binary. So OpenCPN clone some of their reader code. It is beyond
> the scope of this packaging effort to refactor a 3rd party's application.
> (aside: I suspect their debian packaging needs a little work too)

Fair enough I guess. If it isn't possible to use the ZyGrib binary
from the plugin I would suggest to ask ZyGrib upstream to add a
library.

> As for src/mygdal and src/myiso8211, GDAL does supply nice library
> packages but OpenCPN has modified and adapted them. Dave (the OpenCPN
> lead author) had this to say when asked:

Please ask the OpenCPN folks to get their GDAL changes merged
upstream, maybe it will become suitable for OpenCPN use as a result.

> As for src/nmea0183, AFAIK it does not exist in library form elsewhere
> in Debian, and if copyright+Author header comments are anything to go
> by has been specifically tailored/reworked by the OpenCPN lead dev.

Ok. Same comment as for GDAL.

>> src/nmea0183 has no copyright information and this as a license:
>>
>> You can use it any way you like.
>>
>> Unfortunately this does not give Debian permission to copy, modify or
>> distribute.
>
> AFAIU the original author was contacted by upstream, the reply was
>  "It is BSD license, do with it what you will"
> which is now given in the header comments there.

Great.

> The tide and current harmonic data contained herein are derived from the
> corresponding XTIDE harmonic data. The file data have been tweaked to
> work nicely in the US, especially fixing current direction reporting. We
> have also added additional global tide stations, and corrected calculation/
> display units where sensible. A generic XTIDE harmonic file set will be
> functional, but less useful than the harmonic data packaged with OpenCPN.

Would it be possible to merge those changes into the xtide version?

> the package is now lintian clean on squeeze.

Lintian has improved a lot since squeeze, always use the
sid/experimental/backports version.

> I have not looked at those, nor know how they could be addressed.

Fix the upstream build system to not link against stuff the app
doesn't use. Probably some of these are wx's fault though.

> I have not attempted to review or address compiler warnings, but note that
> the code has changed significantly since the above, so best to look at a
> fresh build.

Indeed, especially with GCC having gone through several major versions.

> A matter of personal preference IMO, but upstream has now switched to git.

Indeed, excellent.

>> You have enough work above, but have you also considered packaging
>> wxTide, CapCode and other FLOSS nautical apps?
>
> Xtide is already packaged (AFAIK wxTide is a Windows port of it).
> CapCode is alive!  http://sourceforge.net/apps/trac/capcode/timeline

Cool.

I'll do another review of the package in the next few hours.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Mon, 02 May 2011 03:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Mon, 02 May 2011 03:39:03 GMT) Full text and rfc822 format available.

Message #44 received at 538067@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>, 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Mon, 2 May 2011 11:37:16 +0800
A new review:

There are bound to be more things to fix, I'll do another one when the
issues below are resolved.

Hamish, you should add yourself to the Uploaders, or use `dch --team`
to indicate a GIS team upload.

override_dh_installman shouldn't be needed, best create a
debian/opencpn.manpages file listing the manual page. It should
probably also reference the HTML documentation in the SEE ALSO
section.

I personally like to wrap the Build-Depends line one item per line so
that changes to them are easier to diff.

"cross-platform" isn't relevant in the context of Debian package descriptions.

The package descriptions are duplicates of one another. Please see the
warzone2100 packages for how I think data package descriptions should
look.

Why are you depending on libgps19 manually? Dependencies on libraries
should only be done via the shlibs mechanism.

Your Standards-Version is out of date, please read the upgrading
checklist from the version of debian-policy in sid and do any required
changes:

/usr/share/doc/debian-policy/upgrading-checklist.txt*

You can remove the extra whitespace lines at the end of debian/control.

No need for the blank line in debian/watch.

The watch file doesn't work, please replace it with this:

version=3
http://sf.net/opencpn/OpenCPN-(.+)-Source\.tar\.gz

I'm not sure what the letters mean in the upstream version numbers but
if they mean alpha then I suggest this instead since Debian mainly
prefers upstream blessed as stable versions:

version=3
http://sf.net/opencpn/OpenCPN-([\d\.]+)-Source\.tar\.gz

Please write a get-orig-source debian/rules target since the watch
file does not find the tarball for the version listed in
debian/changelog.

debian/changelog does not close the ITP.

The upstream README file contains information about building and
dependencies, which is not useful to people installing the binary
package. Please get upstream to split that out into README.install so
that it can be shipped in the source package but not the binary
package. Some of the path names may need tweaking for Debian too (/usr
vs /usr/local etc).

Please add DEP-3 compliant headers to the patches:

http://dep.debian.net/deps/dep3/

Please alter the patches until they are acceptable for and included upstream.

plugins/grib_pi/CMakeLists.txt seems to include Windows line endings, eww.

I personally use this in my ~/.quiltrc to generate nice looking
patches with less cruft:

QUILT_REFRESH_ARGS="-pab --no-timestamps --no-index"

I personally like to wrap debian/menu one item per line to make diffs
easier to read.

debian/README.harmonics seems to duplicate data/doc/README.harmonics,
please merge the extra info in the debian one upstream.

Please add --parallel to the invocation of dh so that opencpn can be
built using parallelism.

You can drop lines 2-9 from debian/rules (the comments) and the extra
whitespace.

The xpm file can be installed by dh_install, just edit
debian/opencpn.install to add this (you might need to drop the ../../,
not sure):

../../src/bitmaps/opencpn.xpm usr/share/pixmaps

It would be nice if override_dh_install/override_dh_installdocs wasn't
nessecary, please look at sending upstream patches to fix that by
offering options to not install stuff, install stuff to the right
names and install the plugins in the right dir.

When building the package I noticed that the gcc command-lines had
both -O2 and -O3.

When building twice in a row a new patch is added
(debian-changes-2.4.423-1), looks like this is caused by
include/version.h not being cleaned up by debian/rules clean, please
fix the upstream build system so it does that or add it to
debian/clean.

Why is the MacOS X icon completely different to the normal OpenCPN logo?

Please remove the prebuilt Windows executables from the source tarball
and git repository.

data/doc/images/print.html seems to be a 404 page, please remove it.

data/doc/css/ can probably be used since nothing in the package uses it.

Please remove data/doc/js/. Nothing in the package uses it and it is a
embedded code copy that is minified and therefore is missing the
source code.

A lot of the source code contains CVS $Id lines while the package is
in git, I would suggest to clean those up, especially the CPL_CVSID
ones.

The upstream README file (and many other files) has the executable bit
set, why is that?

The following scripts look like they should be run during the build
process so that any changes to the SVG files are reflected in the
bitmaps. Alternatively they could be merged into the CMake build
system.

plugins/grib_pi/src/icons.sh
plugins/dashboard_pi/src/icons.sh
src/bitmaps/32x32_svg_src/cursor/create_all_32x32.sh
src/bitmaps/32x32_svg_src/ribbon/create_all_32x32.sh
src/bitmaps/13xX_svg_src/create_all_13xX.sh
src/bitmaps/28x28_svg_src/create_all_28x28.sh
src/bitmaps/optimize_png.sh
src/bitmaps/other_svg_src/create_opencpn_main_icon.sh
src/bitmaps/other_svg_src/create_ship.sh
src/bitmaps/16x16_svg_src/create_all_16x16.sh
src/bitmaps/create_all.sh

What is the license for src/bitmaps/paypal_donate.xpm?

Lintian complaints:

W: opencpn source: changelog-should-mention-nmu
W: opencpn source: source-nmu-has-incorrect-version-number 2.4.423-1
W: opencpn: description-synopsis-starts-with-article
P: opencpn: no-upstream-changelog
E: opencpn: embedded-library usr/bin/opencpn: tinyxml
I: opencpn-doc: possible-documentation-but-no-doc-base-registration
W: opencpn source: out-of-date-standards-version 3.8.4 (current is 3.9.2)
P: opencpn source: source-contains-prebuilt-windows-binary
buildwin/NSIS_Unicode/UI/opencpn_ui.exe
P: opencpn source: source-contains-prebuilt-windows-binary
buildwin/NSIS_Unicode/Plugins/w7tbp.dll
P: opencpn source: source-contains-prebuilt-windows-binary
buildwin/NSIS_Unicode/Plugins/UAC.dll
P: opencpn source: source-contains-prebuilt-windows-binary
wxWidgets/wxbase28u_vc_custom.dll
P: opencpn source: source-contains-prebuilt-windows-binary
buildwin/NSIS_Unicode/Plugins/AccessControlW.dll
P: opencpn source: source-contains-prebuilt-windows-binary
buildwin/NSIS_Unicode/Plugins/ShellLink.dll
P: opencpn source: source-contains-prebuilt-windows-binary
wxWidgets/wxbase28u_net_vc_custom.dll
P: opencpn source: source-contains-prebuilt-windows-binary
buildwin/vc9/vcredist_x86.exe
P: opencpn source: source-contains-prebuilt-windows-binary
wxWidgets/wxbase28u_xml_vc_custom.dll
P: opencpn source: source-contains-prebuilt-windows-binary
wxWidgets/wxmsw28u_aui_vc_custom.dll
P: opencpn source: source-contains-prebuilt-windows-binary
wxWidgets/wxmsw28u_adv_vc_custom.dll
P: opencpn source: source-contains-prebuilt-windows-binary
buildwin/NSIS_Unicode/nsis-2.46-Unicode-setup.exe
P: opencpn source: source-contains-prebuilt-windows-binary
wxWidgets/wxmsw28u_core_vc_custom.dll

dpkg-shlibdeps warnings:

dependency on libz.so.1 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libX11.so.6 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libwx_gtk2u_html-2.8.so.0 could be avoided if
"debian/opencpn/usr/bin/opencpn
debian/opencpn/usr/lib/opencpn-plugins/libgrib_pi.so
debian/opencpn/usr/lib/opencpn-plugins/libdashboard_pi.so" were not
uselessly linked against it (they use none of its symbols).
dependency on libwx_baseu_xml-2.8.so.0 could be avoided if
"debian/opencpn/usr/bin/opencpn
debian/opencpn/usr/lib/opencpn-plugins/libgrib_pi.so
debian/opencpn/usr/lib/opencpn-plugins/libdashboard_pi.so" were not
uselessly linked against it (they use none of its symbols).
dependency on libbz2.so.1.0 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libglib-2.0.so.0 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libatk-1.0.so.0 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libXext.so.6 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libgdk_pixbuf-2.0.so.0 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libcairo.so.2 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libpango-1.0.so.0 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libSM.so.6 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libfreetype.so.6 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libICE.so.6 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libGL.so.1 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).
dependency on libgdk-x11-2.0.so.0 could be avoided if
"debian/opencpn/usr/bin/opencpn" were not uselessly linked against it
(they use none of its symbols).

Some gcc and ld warnings:

src/s52plib.cpp: In member function 'int s52plib::dda_tri(wxPoint*,
S52color*, render_canvas_parms*, render_canvas_parms*)':
src/s52plib.cpp:5158:21: warning: 'r' may be used uninitialized in this function
src/s52plib.cpp:5158:24: warning: 'g' may be used uninitialized in this function
src/s52plib.cpp:5158:27: warning: 'b' may be used uninitialized in this function

src/s57chart.cpp: In member function 'void
s57chart::CreateSENCRecord(OGRFeature*, FILE*, int, S57Reader*)':
src/s57chart.cpp:4796:53: warning: format '%d' expects type 'int', but
argument 3 has type 'size_t'

src/tri.c:125:1: warning: 'cvsid_aw' defined but not used

src/myiso8211/ddfrecord.cpp: In member function 'int DDFRecord::Write()':
src/myiso8211/ddfrecord.cpp:285:58: warning: format '%05d' expects
type 'int', but argument 3 has type 'size_t'
src/myiso8211/ddfrecord.cpp:289:64: warning: format '%05d' expects
type 'int', but argument 3 has type 'size_t'

src/chart1.cpp: In member function 'bool MyFrame::DoChartUpdate()':
src/chart1.cpp:6372:142: warning: suggest parentheses around '&&' within '||'

src/chcanv.cpp: In member function 'void TCWin::OnPaint(wxPaintEvent&)':
src/chcanv.cpp:10927:79: warning: suggest parentheses around
comparison in operand of '=='

src/cutil.c:62:1: warning: 'cvsid_aw' defined but not used

src/georef.c:72:1: warning: 'cvsid_aw' defined but not used

src/tcmgr.cpp: In member function 'void
TCMgr::GetHightOrLowTide(time_t, int, int, float, bool, int, float&,
time_t&)':
src/tcmgr.cpp:754:36: warning: suggest parentheses around comparison
in operand of '=='
src/tcmgr.cpp:762:31: warning: suggest parentheses around comparison
in operand of '=='
src/tcmgr.cpp: In member function 'Station_Data*
TCMgr::find_or_load_harm_data(IDX_entry*)':
src/tcmgr.cpp:1057:63: warning: array subscript is below array bounds
src/tcmgr.cpp: In member function 'double TCMgr::blend_tide(time_t,
int, int, double)':
src/tcmgr.cpp:2857:15: warning: array subscript is below array bounds

src/gpxdocument.cpp: In static member function 'static int
GpxDocument::GetRandomNumber(int, int)':
src/gpxdocument.cpp:131:52: warning: integer overflow in expression

plugins/dashboard_pi/src/dashboard_pi.cpp: In member function 'void
DashboardWindow::SetInstrumentList(wxArrayInt)':
plugins/dashboard_pi/src/dashboard_pi.cpp:1539:34: warning:
'instrument' may be used uninitialized in this function

/usr/bin/ld: Warning: alignment 4 of symbol `gps_link_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_waypt_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_category_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_rte_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_rte_link_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_trk_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_trk_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_run_crs_trk_hdr_type'
in libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_run_crs_trk_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_prx_waypt_transfer'
in libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_prx_waypt_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_almanac_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_almanac_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_position_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_position_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_pvt_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_pvt_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_waypt_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_lap_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_lap_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_workout_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_workout_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol
`gps_workout_occurrence_type' in libGARMINHOST.a(garmin_wrapper.cpp.o)
is smaller than 16 in libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol
`gps_user_profile_transfer' in libGARMINHOST.a(garmin_wrapper.cpp.o)
is smaller than 16 in libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_user_profile_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol
`gps_workout_limits_transfer' in libGARMINHOST.a(garmin_wrapper.cpp.o)
is smaller than 16 in libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_course_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_course_lap_transfer'
in libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_course_lap_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol
`gps_course_point_transfer' in libGARMINHOST.a(garmin_wrapper.cpp.o)
is smaller than 16 in libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_course_point_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol
`gps_course_limits_transfer' in libGARMINHOST.a(garmin_wrapper.cpp.o)
is smaller than 16 in libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_category_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsapp.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_category_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_waypt_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_trk_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_prx_waypt_transfer'
in libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_almanac_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_position_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_pvt_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_lap_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol
`gps_course_point_transfer' in libGARMINHOST.a(garmin_wrapper.cpp.o)
is smaller than 16 in libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol
`gps_course_limits_transfer' in libGARMINHOST.a(garmin_wrapper.cpp.o)
is smaller than 16 in libGARMINHOST.a(gpscom.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_link_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_waypt_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_waypt_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_rte_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_trk_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_trk_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_prx_waypt_transfer'
in libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 8 of symbol `gps_prx_waypt_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_almanac_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_almanac_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsprot.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_position_transfer' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsrqst.c.o)
/usr/bin/ld: Warning: alignment 4 of symbol `gps_position_type' in
libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in
libGARMINHOST.a(gpsrqst.c.o)

-- 
bye,
pabs

http://wiki.debian.org/PaulWise




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sat, 18 Jun 2011 14:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sat, 18 Jun 2011 14:33:03 GMT) Full text and rfc822 format available.

Message #49 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>
Cc: Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>, 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Sat, 18 Jun 2011 07:29:52 -0700 (PDT)
Hi,

an update on ITP progress for the OpenCPN software (opencpn.org).

Before Anton formally requests the next review, I though I'd take care of
commenting on and clearing out as much of the old business as I can.

the debian/ dir can be viewed here:
   http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/

the .orig tarball with the dll and exe ms-windows port binary stuff removed
can be found here:
   http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/


On Feb 8, 2011, Paul Wise wrote:
> > macsercomm.cpp looks slightly suspect. I'd like to know its lineage,
> > copyright and license. Same for macutils.c
[+]
> > sercomm.cpp macsercomm.h macutils.h
> > sercomm.h

Hamish replied:
> src/about.cpp lists seriallib as being GPL.
> We can request better header comments.

requested, waiting.
  http://www.opencpn.org/flyspray/index.php?do=details&task_id=442

Hamish:
> Convincing OpenCPN, Xtide, ZyGrib, and GMT, ..? to all consolidate on the
> same world vector coastline data remains a TODO (I'd humbly suggest
> focusing on GMT's version(s) of GSHHS as the standard), but remains beyond
> the scope of this [OpenCPN] packaging effort.

I notice others have the same idea,
  http://wiki.debian.org/DebianScience/Meteorology (bottom of the page)
  http://wiki.debian.org/DebianScienceGshhsMaps
  see also earlier discussions on the debian-gis mailing list (pkg-grass@alioth actually)

for now OpenCPN depends on the xtide-coastline package for its needs.


> "dpkg-shlibdeps: warning: dependency ... needlessly depends on ..."

we suspect these are false positives from WxWidgets/cmake.


On May 1, 2011, Paul Wise wrote:
> Generally one should build and test using the suite you are uploading
> to. Most uploads go to sid so they should be built and tested there.

I now have installed a sid VM for that.
Frankie encountered an assembly build error in a previous beta but it
builds without fault for me. Dave suggested that __INTEL__ might trigger
it; but I only have AMD to test on so I can't confirm.

> > The cmake rules are patched to use the system's zlib, bzip2 if UNIX. 
...
> Fair enough. Please remove the embedded code copies before
> debian/rules build (or configure) so that the Debian package can never
> build against it by accident.

mmph, IMO .orig should mean "orig", and the .diff should take care of
the cleanup needed for Debianization. (the exception being dfsg
incompatible stuff) Lintian will alert us if a change in the cmake rules
re-embed the libs. (which are supplied for building the MS-Windows/Mac ports)

> Please ask the OpenCPN folks to get their GDAL changes merged
> upstream, maybe it will become suitable for OpenCPN use as a result.

AFAIU, the changes are not considered useful/desired for others, so 
intentionally not pushed upstream to GDAL.


> > The tide and current harmonic data [...]
> Would it be possible to merge those changes into the xtide version?

It would be nice, but probably not. They have their own ideas and goals,
and have implemented them. AFAIU OpenCPN has decided something else is
needed, and to take it on their own path with that.


> Lintian has improved a lot since squeeze, always use the
> sid/experimental/backports version.

ok, sid's lintian now reports:
 E: opencpn-data: helper-templates-in-copyright
 E: opencpn: embedded-library usr/bin/opencpn: tinyxml
 E: opencpn: helper-templates-in-copyright
 E: opencpn-doc: helper-templates-in-copyright

tinyxml: not sure, exists to be embedded? suggestions to fix that welcome.

helper-templates-in-copyright x3: I don't see what it's talking about, the
 debian/copyright files are custom crafted.


compiler warnings:
 upstream supplied with latest sid build log, nearly almost all squashed.

valgrind analysis:
 status unknown. (personal ignorance on my part of what's been done)


> Hamish, you should add yourself to the Uploaders, or use `dch --team`
> to indicate a GIS team upload.

done, but this is still Anton's to lead, working under the guise of the
DebianGIS team (the control file's maintainer of note).
We can worry about that in the final hours before formal submission to the
FTP masters.

> override_dh_installman shouldn't be needed, best create a
> debian/opencpn.manpages file listing the manual page. It should
> probably also reference the HTML documentation in the SEE ALSO
> section.

done, done, & done.

> I personally like to wrap the Build-Depends line one item per line
> so that changes to them are easier to diff.

In general I heartily agree, and if it wrapped onto a third line I'd do
it. But the current two <80 column lines satisfy the easy-clarity req's
IMO and so I've left it as-is.

> "cross-platform" isn't relevant in the context of Debian package descriptions.

ok, gone.

> The package descriptions are duplicates of one another.

ok, reduced.

> Why are you depending on libgps19 manually? Dependencies on libraries
> should only be done via the shlibs mechanism.

yeah I know. It's there as an explicit reminder that there'll likely be
trouble when the upcoming libgps20 is transitioned into sid.


> Your Standards-Version is out of date, please read the upgrading
> checklist from the version of debian-policy in sid and do any required
> changes:   /usr/share/doc/debian-policy/upgrading-checklist.txt*

-> TODO
(want to take that one Anton?)


> You can remove the extra whitespace lines at the end of debian/control.
> No need for the blank line in debian/watch.

ok, both gone.

> The watch file doesn't work, please replace it with this:

done.

> I'm not sure what the letters mean in the upstream version numbers but
> if they mean alpha then I suggest this instead since Debian mainly
> prefers upstream blessed as stable versions:

currently we are packaging late betas for the upcoming (this month?) stable
release. After that we'll track the stable releases for official packages.

> Please write a get-orig-source debian/rules target since the watch
> file does not find the tarball for the version listed in
> debian/changelog.

An .orig tarball with the dll and exe ms-windows port binary stuff removed
can now be found here:
   http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/

It is likely this area can be further automated.
I would still aim the watch file at the official SourceForge site.
Props to Frankie for helping with this.

> debian/changelog does not close the ITP.

I consider that a last-minute task for when we have passed review and are
ready to submit for upload.

> The upstream README file contains information about building and
> dependencies, which is not useful to people installing the binary
> package. Please get upstream to split that out into README.install so
> that it can be shipped in the source package but not the binary
> package. Some of the path names may need tweaking for Debian too (/usr
> vs /usr/local etc).

presumably if debian users are reading that, they already have it built
and the non-conforming info is irrelevant to them.
I agree that splitting the file into INSTALL and README would be a good idea.

> Please add DEP-3 compliant headers to the patches:
> http://dep.debian.net/deps/dep3/

done.

> Please alter the patches until they are acceptable for and included upstream.

I think the only one left which isn't wholly about conforming to Debianisms
is the location of the plugins lib dir. Suggested on the upstream forums but
no feedback to report yet --anyway, low priority and the difference is noted
in the README.Debian file.

> plugins/grib_pi/CMakeLists.txt seems to include Windows line endings, eww.

reported upstream:
  http://www.opencpn.org/flyspray/index.php?do=details&task_id=420

> I personally use this in my ~/.quiltrc to generate nice looking
> patches with less cruft:
> QUILT_REFRESH_ARGS="-pab --no-timestamps --no-index"

I'm a big fan of as many breadcrumbs/much metadata as humanly possible,
and abhor throwing away data which may help to work backwards later on, as usually I need all the clues that I can get.

> I personally like to wrap debian/menu one item per line to make diffs
> easier to read.

agreed, done.

> debian/README.harmonics seems to duplicate data/doc/README.harmonics,
> please merge the extra info in the debian one upstream.

It replaces it, see the last line of the rules file.
The debian/ version goes into a little more history/detail to explain
how it fits in with other debian packages.

> Please add --parallel to the invocation of dh so that opencpn can be
> built using parallelism.

I tried that on my 6-core Squeeze box, but it did not change build time
at all, so I've left it "clean". It would be nice to have working though.
  ??

> You can drop lines 2-9 from debian/rules (the comments) and the extra
> whitespace.

boilerplace stuff removed.

> The xpm file can be installed by dh_install, just edit
> debian/opencpn.install to add this

done.

> It would be nice if override_dh_install/override_dh_installdocs wasn't
> nessecary,

done/removed.

> When building the package I noticed that the gcc command-lines had
> both -O2 and -O3.

-> TODO
(Dave?)

> When building twice in a row a new patch is added
> (debian-changes-2.4.423-1), looks like this is caused by
> include/version.h not being cleaned up by debian/rules clean, please
> fix the upstream build system so it does that

done upstream.

> Why is the MacOS X icon completely different to the normal OpenCPN logo?

no idea, but now it's gone in our +dfsg.orig tarball.

> Please remove the prebuilt Windows executables from the source tarball

done. (now we make a stripped +dfsg.orig.tar.gz in alioth svn)

> and git repository.

suggested in upstream forums.

> data/doc/images/print.html seems to be a 404 page, please remove it.

filed upstream:
  http://www.opencpn.org/flyspray/index.php?do=details&task_id=538

> data/doc/css/ can probably be used since nothing in the package uses it.
> Please remove data/doc/js/. Nothing in the package uses it and it is a
> embedded code copy that is minified and therefore is missing the
> source code.

I was under the assumption that it was being used.
(Dave?)

> A lot of the source code contains CVS $Id lines while the package is
> in git, I would suggest to clean those up, especially the CPL_CVSID
> ones.

Filed upstream as FS#539.

> The upstream README file (and many other files) has the executable bit
> set, why is that?

Filed upstream as FS#420  (see above about DOS newlines)

> The following scripts look like they should be run during the build
> process so that any changes to the SVG files are reflected in the
> bitmaps. Alternatively they could be merged into the CMake build
> system.
> 
> plugins/grib_pi/src/icons.sh
> plugins/dashboard_pi/src/icons.sh
> src/bitmaps/32x32_svg_src/cursor/create_all_32x32.sh
> src/bitmaps/32x32_svg_src/ribbon/create_all_32x32.sh
> src/bitmaps/13xX_svg_src/create_all_13xX.sh
> src/bitmaps/28x28_svg_src/create_all_28x28.sh
> src/bitmaps/optimize_png.sh
> src/bitmaps/other_svg_src/create_opencpn_main_icon.sh
> src/bitmaps/other_svg_src/create_ship.sh
> src/bitmaps/16x16_svg_src/create_all_16x16.sh
> src/bitmaps/create_all.sh

src/bitmaps/README.TXT says:
"""
1. Run create_all.sh

Creation scripts require:
ImageMagick
Inkscape
Optipng
Icoutils
png2wx.pl
"""

avoiding those as build-deps seems to outweigh the possibility of stale
xpm/png files. FWIW all generated files seem younger than 8 weeks, so I
suspect are kept up to date with regularity.

> What is the license for src/bitmaps/paypal_donate.xpm?

-> TODO
I don't know, but we need to find out as a priority.

> Lintian complaints:
> dpkg-shlibdeps warnings:
> Some gcc and ld warnings:

see comments earlier in this email.



thanks & regards,
Hamish





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sun, 19 Jun 2011 06:48:55 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sun, 19 Jun 2011 06:48:55 GMT) Full text and rfc822 format available.

Message #54 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>
Cc: 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Sat, 18 Jun 2011 23:34:14 -0700 (PDT)
[several issues mentioned in yesterday's summary have now been
fixed upstream, more on that soon]

Paul wrote:
> > What is the license for src/bitmaps/paypal_donate.xpm?

Hamish:
> -> TODO
> I don't know, but we need to find out as a priority.

I've no answer, but I notice that `apt-file search paypal` turns
up a handful of other debian packages in the same boat, for good
or bad.

If it is deemed to be copyright/trademark problematic, there
should be no trouble going the iceweasel custom graphic route,
although "Donate now via a company we can't name" doesn't have
the same ring to it. (even if it does bring up memories of Joe's
Garage :)

what's the license attached to the debian graphics for iceweasel?


Hamish





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sun, 19 Jun 2011 07:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sun, 19 Jun 2011 07:00:03 GMT) Full text and rfc822 format available.

Message #59 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>
Cc: 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Sat, 18 Jun 2011 23:57:11 -0700 (PDT)
Paul:
> When building the package I noticed that the gcc command-lines
> had both -O2 and -O3.


-O3 is added by OpenCPN's CMakeLists.txt:
---
IF(NOT WIN32)
  ADD_DEFINITIONS( "-Wall -g -fexceptions -rdynamic" )
  ADD_DEFINITIONS( "-O3 -fno-strict-aliasing")
ENDIF(NOT WIN32)
---


-O2 seems to come from debuild:  (which then puts it into
obj-x86_64-linux-gnu/CMakeCache.txt)
---
dpkg-buildpackage -rfakeroot -D -us -uc -i -b
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): 
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): 
dpkg-buildpackage: source package opencpn
dpkg-buildpackage: source version 2.4.612-1
[...]
---

["origin: vendor"??]


which one to keep and which one to drop?

if dpkg-buildpackage's is to be dropped, how would one accomplish
that in the rules file?


thanks,
Hamish





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Mon, 20 Jun 2011 10:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Mon, 20 Jun 2011 10:03:06 GMT) Full text and rfc822 format available.

Message #64 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>
Cc: Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>, 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Mon, 20 Jun 2011 03:01:04 -0700 (PDT)
Hi,

(another) update on ITP progress for the OpenCPN software (opencpn.org),

Fixes noted in this email are in the new 2.4.620 release.


> the debian/ dir can be viewed here:
>    http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/
> 
> the .orig tarball can be found here:
>    http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/

sample data to test it with can be found here:
  https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/install_opencpn.sh#L75


> On Feb 8, 2011, Paul Wise wrote:
> > > macsercomm.cpp looks slightly suspect. I'd like to know its lineage,
> > > copyright and license. Same for macutils.c
> [+]
> > > sercomm.cpp macsercomm.h macutils.h
> > > sercomm.h
> 
> Hamish replied:
> > src/about.cpp lists seriallib as being GPL.
> > We can request better header comments.

Dave wrote:
> DONE...gpl for macutils, macsercomm is deprecated.


Hamish:
> ok, sid's lintian now reports:
>  E: opencpn-data: helper-templates-in-copyright
>  E: opencpn: embedded-library usr/bin/opencpn: tinyxml
>  E: opencpn: helper-templates-in-copyright
>  E: opencpn-doc: helper-templates-in-copyright
> 
> tinyxml: not sure, exists to be embedded? suggestions to
> fix that welcome.
> 
> helper-templates-in-copyright x3: I don't see what it's
> talking about, the debian/copyright files are custom crafted.

Advice welcome.


> compiler warnings:
>  upstream supplied with latest sid build log, nearly almost
> all squashed.

ongoing; it's getting there.

 
> valgrind analysis:
>  status unknown. (personal ignorance on my part of what's been done)

Volunteers welcome.


> > Your Standards-Version is out of date, please read the upgrading
> > checklist from the version of debian-policy in sid and do any required
> >
> changes:   /usr/share/doc/debian-policy/upgrading-checklist.txt*
 
To do


> > The upstream README file contains information about building and
> > dependencies, which is not useful to people installing the binary
> > package. Please get upstream to split that out into README.install so
> > that it can be shipped in the source package but not the binary
> > package. Some of the path names may need tweaking for Debian too (/usr
> > vs /usr/local etc).

Install stuff now split off from README; INSTALL file not installed in
the binary packages (although perhaps the serial port setup stuff may
be useful to someone, somewhen).


> > plugins/grib_pi/CMakeLists.txt seems to include Windows line endings,
> > eww.

fixed.


> > When building the package I noticed that the gcc command-lines had
> > both -O2 and -O3.

fixed.


> > data/doc/images/print.html seems to be a 404 page, please remove it.

done.


> > data/doc/css/ can probably be used since nothing in the package uses
> > it.
> > Please remove data/doc/js/. Nothing in the package uses it and it is a
> > embedded code copy that is minified and therefore is missing the
> > source code.

removed.


> > A lot of the source code contains CVS $Id lines while the package is
> > in git, I would suggest to clean those up, especially the CPL_CVSID
> > ones.
> 
> Filed upstream as FS#539.

still some remain.


> > The upstream README file (and many other files) has the executable bit
> > set, why is that?

fixed.


> > What is the license for src/bitmaps/paypal_donate.xpm?

PayPal pinged for an answer, awaiting reply.
see also `apt-file search paypal`


Hamish





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sun, 26 Jun 2011 09:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sun, 26 Jun 2011 09:42:03 GMT) Full text and rfc822 format available.

Message #69 received at 538067@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>, 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Sun, 26 Jun 2011 10:39:50 +0100
On Sat, Jun 18, 2011 at 3:29 PM, Hamish <hamish_b@yahoo.com> wrote:

> mmph, IMO .orig should mean "orig", and the .diff should take care of
> the cleanup needed for Debianization. (the exception being dfsg
> incompatible stuff) Lintian will alert us if a change in the cmake rules
> re-embed the libs. (which are supplied for building the MS-Windows/Mac ports)

I wasn't talking about repacking the tarball, but adding "rm -r
path/to/embedded/code/copies" to debian/rules build. This ensures that
the package will never build against the embedded code. You can never
be sure if the person doing the upload will run lintian, nor that
lintian knows about the specific embedded code copies you are using.
Think of it as an additional safety net.

>> Please ask the OpenCPN folks to get their GDAL changes merged
>> upstream, maybe it will become suitable for OpenCPN use as a result.
>
> AFAIU, the changes are not considered useful/desired for others, so
> intentionally not pushed upstream to GDAL.

Hmmm.

>> > The tide and current harmonic data [...]
>> Would it be possible to merge those changes into the xtide version?
>
> It would be nice, but probably not. They have their own ideas and goals,
> and have implemented them. AFAIU OpenCPN has decided something else is
> needed, and to take it on their own path with that.
>
>
>> Lintian has improved a lot since squeeze, always use the
>> sid/experimental/backports version.
>
> ok, sid's lintian now reports:
>  E: opencpn-data: helper-templates-in-copyright
>  E: opencpn: embedded-library usr/bin/opencpn: tinyxml
>  E: opencpn: helper-templates-in-copyright
>  E: opencpn-doc: helper-templates-in-copyright
>
> tinyxml: not sure, exists to be embedded? suggestions to fix that welcome.

Build-Depend on libtinyxml-dev and add any patches needed to build
against the system version.

> helper-templates-in-copyright x3: I don't see what it's talking about, the
>  debian/copyright files are custom crafted.

http://lintian.debian.org/tags/helper-templates-in-copyright.html

> yeah I know. It's there as an explicit reminder that there'll likely be
> trouble when the upcoming libgps20 is transitioned into sid.

What kind of issue?

> An .orig tarball with the dll and exe ms-windows port binary stuff removed
> can now be found here:
>   http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/

Hmm, a tarball in SVN,

> It is likely this area can be further automated.
> I would still aim the watch file at the official SourceForge site.

Definitely.

>> debian/changelog does not close the ITP.
>
> I consider that a last-minute task for when we have passed review and are
> ready to submit for upload.

Eh? It wouldn't pass review without it.

> I think the only one left which isn't wholly about conforming to Debianisms
> is the location of the plugins lib dir. Suggested on the upstream forums but
> no feedback to report yet --anyway, low priority and the difference is noted
> in the README.Debian file.

> I tried that on my 6-core Squeeze box, but it did not change build time
> at all, so I've left it "clean". It would be nice to have working though.
>  ??

I guess the upstream build system does not support it.

> avoiding those as build-deps seems to outweigh the possibility of stale
> xpm/png files. FWIW all generated files seem younger than 8 weeks, so I
> suspect are kept up to date with regularity.

I don't think graphics should be treated any differently to programs
wrt building and source code. We don't ship precompiled executables
in/from source packages, why should graphics be any different?


Thanks for pushing this ITP forward.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sun, 26 Jun 2011 09:54:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sun, 26 Jun 2011 09:54:08 GMT) Full text and rfc822 format available.

Message #74 received at 538067@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Sun, 26 Jun 2011 10:51:51 +0100
On Sun, Jun 19, 2011 at 7:34 AM, Hamish <hamish_b@yahoo.com> wrote:

> I've no answer, but I notice that `apt-file search paypal` turns
> up a handful of other debian packages in the same boat, for good
> or bad.
>
> If it is deemed to be copyright/trademark problematic, there
> should be no trouble going the iceweasel custom graphic route,
> although "Donate now via a company we can't name" doesn't have
> the same ring to it. (even if it does bring up memories of Joe's
> Garage :)

Its unlikely that the paypal graphics are DFSG-free, so I think we
need to remove them.

I personally don't have time to investigate this issue, but I see 8
images in binary packages and ~ 11 images in source packages, based on
the Contents files.

I wonder about the best course of action here, some ideas:

Filing RC bugs for the cases listed in the Contents files after investigation

Adding a lintian warning based on known md5sums of paypal graphics to
prevent future issues. The old and new logos are here:

https://www.paypal.com/newlogobuttons

> what's the license attached to the debian graphics for iceweasel?

From sid /usr/share/doc/iceweasel/copyright:

Files: debian/*
Copyright: 2005-2010, Mike Hommey <glandium@debian.org>
License: MPL-1.1 or GPL-2 or LGPL-2.1

-- 
bye,
pabs

http://wiki.debian.org/PaulWise




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sun, 26 Jun 2011 12:58:52 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sun, 26 Jun 2011 12:58:54 GMT) Full text and rfc822 format available.

Message #79 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, 538067@bugs.debian.org
Subject: Re: RFS: opencpn
Date: Sun, 26 Jun 2011 05:19:12 -0700 (PDT)
Hamish:
> > I've no answer, but I notice that `apt-file search
> > paypal` turns up a handful of other debian packages in the
> > same boat, for good or bad.
> >
> > If it is deemed to be copyright/trademark problematic,
> > there should be no trouble going the iceweasel custom
> > graphic route, ...
Paul W:
> Its unlikely that the paypal graphics are DFSG-free, so I
> think we need to remove them.

as it happens Dave emailed me yesterday to say that he'd given
up on Paypal replying with clarification and gone ahead and
designed a custom graphic to replace it, available in the next
code push.

OpenCPN is GPL, but I suspect we can convince the author to
relicense as needed for whatever other deb packages need to use
the dfsg substitute..

> Filing RC bugs for the cases listed in the Contents files
> after investigation

(& attaching a sugested replacement along with the ticket..)


cheers,
Hamish





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sun, 26 Jun 2011 13:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sun, 26 Jun 2011 13:15:04 GMT) Full text and rfc822 format available.

Message #84 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, 538067@bugs.debian.org
Cc: Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>
Subject: Re: RFS: opencpn
Date: Sun, 26 Jun 2011 06:07:08 -0700 (PDT)
Paul W wrote:
> I wasn't talking about repacking the tarball, but adding
> "rm -r path/to/embedded/code/copies" to debian/rules build.
> This ensures that the package will never build against the
> embedded code. You can never be sure if the person doing the
> upload will run lintian, nor that lintian knows about the
> specific embedded code copies you are using. Think of it as an
> additional safety net.

This possibility is not something which would keep me awake at
night, but no harm in it, so will do.


Hamish:
> > ok, sid's lintian now reports:
> >  E: opencpn-data: helper-templates-in-copyright
> >  E: opencpn: embedded-library usr/bin/opencpn: tinyxml
> >  E: opencpn: helper-templates-in-copyright
> >  E: opencpn-doc: helper-templates-in-copyright
> >
> > tinyxml: not sure, exists to be embedded? suggestions
> > to fix that welcome.
> 
> Build-Depend on libtinyxml-dev and add any patches needed
> to build against the system version.

ok, versions only differ by 0.0.1, will do.


> > helper-templates-in-copyright x3: I don't see what
> > it's talking about, the  debian/copyright files are custom
> > crafted.
> 
> http://lintian.debian.org/tags/helper-templates-in-copyright.html

Have a look at the file(s) in question, I'm fairly sure that's
a false positive.


> > yeah I know. It's there as an explicit reminder that
> > there'll likely be trouble when the upcoming libgps20 is
> > transitioned into sid.
> 
> What kind of issue?

http://gpsd.berlios.de/protocol-transition.html


> > An .orig tarball with the dll and exe ms-windows port
> > binary stuff removed can now be found here:
> >   http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/
> 
> Hmm, a tarball in SVN,

http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2011-June/010184.html

I feel your cringe, but we need a stable, controlled place with
history to house the dfsg version of the source tarball; so
$alioth is it. We could check it in uncompressed, but as the
versioned release is static and should be immutable, and all we
want is the tarball, it would seem to me that the current
solution's benefits outweigh its shortcomings.

> >> debian/changelog does not close the ITP.
> >
> > I consider that a last-minute task for when we have
> > passed review and are ready to submit for upload.
> 
> Eh? It wouldn't pass review without it.

ok, so noted as a last-minute todo once everything else in the
review is checked off. (I'd like it as the most modern thing
in the changelog once the package is ready for upload / don't
like crossing things off before they are done)


> > avoiding those as build-deps seems to outweigh the
> > possibility of stale xpm/png files. FWIW all generated files
> > seem younger than 8 weeks, so I suspect are kept up to date
> > with regularity.
> 
> I don't think graphics should be treated any differently to
> programs wrt building and source code. We don't ship precompiled
> executables in/from source packages, why should graphics be any
> different?

prebuilt graphics are a heck of a lot easier to review, modify,
and adapt than auditing and hex-editing binary executables? (well,
you asked..)
It's really the added weight of Inkscape et al. as build-deps
which makes me not mind the risk of slightly stale icons too much.


> Thanks for pushing this ITP forward.

ditto,
Hamish





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sun, 26 Jun 2011 16:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sun, 26 Jun 2011 16:27:03 GMT) Full text and rfc822 format available.

Message #89 received at 538067@bugs.debian.org (full text, mbox):

From: Paul Wise <pabs@debian.org>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, 538067@bugs.debian.org, Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>
Subject: Re: RFS: opencpn
Date: Sun, 26 Jun 2011 17:25:43 +0100
On Sun, Jun 26, 2011 at 2:07 PM, Hamish <hamish_b@yahoo.com> wrote:

> http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2011-June/010184.html
>
> I feel your cringe, but we need a stable, controlled place with
> history to house the dfsg version of the source tarball; so
> $alioth is it. We could check it in uncompressed, but as the
> versioned release is static and should be immutable, and all we
> want is the tarball, it would seem to me that the current
> solution's benefits outweigh its shortcomings.

Another solution is to use the alioth web space, like pkg-games do:

http://pkg-games.alioth.debian.org/tarballs/

> prebuilt graphics are a heck of a lot easier to review, modify,
> and adapt than auditing and hex-editing binary executables? (well,
> you asked..)
> It's really the added weight of Inkscape et al. as build-deps
> which makes me not mind the risk of slightly stale icons too much.

It really depends on your skill set as to which is easier, but neither
pre-built graphics or pre-built executables are source or the
preferred form for modification.

The particular downside of not building graphics every time is that
eventually you find out that at some point something changed and you
can no longer reproducibly build them or they do build but look
completely different. Or your separate repository for the sources goes
missing and you have to recreate from scratch if you want to modify
them. If you build with every upload you notice that sooner. This
especially true for renderings of 3D scenes.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Fri, 01 Jul 2011 07:57:21 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Fri, 01 Jul 2011 07:57:22 GMT) Full text and rfc822 format available.

Message #94 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>
Cc: 538067@bugs.debian.org, Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>
Subject: Re: RFS: opencpn
Date: Fri, 1 Jul 2011 00:54:39 -0700 (PDT)
Hi,

an update on ITP progress for the OpenCPN software (opencpn.org).


| the debian/ dir can be viewed here:
|    http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/
|
| the .orig tarball can be found here:
|    http://pkg-grass.alioth.debian.org/tarballs/
|
|sample data to test it with can be found here:
| https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/install_opencpn.sh#L75


wrt open issues that I'm aware of:


re. upstream +dfsg version of the tarball in alioth svn:
Paul Wise wrote:
> Another solution is to use the alioth web space, like pkg-games do:
> http://pkg-games.alioth.debian.org/tarballs/

--ok, created  http://pkg-grass.alioth.debian.org/tarballs/
with audit-trail md5sum held in alioth svn



re. prebuilt icons vs. build-depends on Inkscape to regenerate
them from svn each time:
--no action taken.



re. paypal graphics:
--gave up on waiting for a reply from them. replaced by a nice substitute graphic from upstream.
we should consider filing bugs against others found by `apt-file search`, but our replacement is not generic enough for other projects to use directly. (as it includes the opencpn logo)


re. dropping unused embedded code as part of debian/rules
--done.


> Build-Depend on libtinyxml-dev and add any patches needed to
> build against the system version.

--done.
note the library doesn't exist before squeeze,maverick.
Added README.lucid to explain how to back-build there (& for lenny).


> > helper-templates-in-copyright x3: I don't see what it's talking about,
> > the debian/copyright files are custom crafted.
> http://lintian.debian.org/tags/helper-templates-in-copyright.html

--false positive


>> debian/changelog does not close the ITP.

--done.


re. support debhelper --parallel
--done, works. (earlier problems were PBKAC)


re. executable bit set on regular text files
--fixed upstream, mostly in the current beta release, the few stragglers are already fixed for the next one.


> > compiler warnings:

there are a few warnings we're not sure how to fix. no segfaults reported..
?
src/garmin/jeeps/gpsusbcommon.c:
  "warning: array subscript is above array bounds [-Warray-bounds]"
?
and many like these:
/usr/bin/ld: Warning: alignment 8 of symbol `gps_waypt_type' in libGARMINHOST.a(garmin_wrapper.cpp.o) is smaller than 16 in libGARMINHOST.a(gpsapp.c.o)
?


> > valgrind analysis:
--volunteers welcome.


> > Your Standards-Version is out of date,
--todo.


> > A lot of the source code contains CVS $Id lines
--further cleaned out in the lastest push.



thanks,
Hamish




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#538067; Package wnpp. (Sat, 09 Jul 2011 20:30:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Anton Martchukov <anton@martchukov.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sat, 09 Jul 2011 20:30:06 GMT) Full text and rfc822 format available.

Message #99 received at 538067@bugs.debian.org (full text, mbox):

From: Anton Martchukov <anton@martchukov.com>
To: 538067@bugs.debian.org
Cc: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, David S Register <bdbcat@yahoo.com>
Subject: Re: Bug#538067: RFS: opencpn
Date: Sat, 9 Jul 2011 23:52:48 +0400
On Sat, Jun 18, 2011 at 07:29:52AM -0700, Hamish wrote:
> an update on ITP progress for the OpenCPN software (opencpn.org).

Another update about OpenCPN package. 

debian directory in svn is updated to build against 2.4.708,
there where problems with tinyxml patch and I fixed them.

1. Since we are using dfsg tarball I think the version
should include "+dfsg" otherwise my pbuilder fails to find
the tarball. I have added this to changelog.

Main thing is that I have produce DEP-5 compilant copyright
file:

http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/debian/copyright?view=markup

I believe there are missing items and issues still. So we
need to review this. But after that copyright things should
be clear for everybody, even for robots. Particular items
that I have questions:

2. src/nmea0183/* plugins/*/src/nmea0183/* have the following:

 *   Copyright (C) 2010 by Samuel R. Blackburn, David S Register
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; either version 2 of the License, or     *
 *   (at your option) any later version.

 *   S Blackburn's original source license:                                *
 *         "You can use it any way you like."                              *
 *   More recent (2010) license statement:                                 *
 *         "It is BSD license, do with it what you will"                   *

So it is not clear which license it is under now? If it is
BSD than which clause version and why GPL header? If it has
been relicensed to GPL than I am not sure if it is possible
to do so providing the given statement from author?

3. plugins/grib_pi/src/Grib* plugins/grib_pi/src/Iso* plugins/grib_pi/src/ZuFile
are taken fron ZyGrib and licensed as GPL-3+. Our code is
GPL-2+ and I think it is not backward compatible. However as
I understand this item is a plugin, so maybe it is ok, but
not sure. 

4. Image files. We need to add them to the copyright file
and understand their licenses and copyright owners.

5. Any other exceptions in source code. Will need to check
for them and add to copyright file.

Beside this there are some less hard issues:

6. Plugins are still installed to /usr/lib/opencpn although
empty directory /usr/lib/opencpn_plugins is being created.

7. Lintian proposes to register the documentation with
doc-base. I am going to study it, but does it make any sense
for our package?

Thanks.

-- 
Anton Martchukov
http://www.martchukov.com




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sat, 09 Jul 2011 22:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sat, 09 Jul 2011 22:00:03 GMT) Full text and rfc822 format available.

Message #104 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: 538067@bugs.debian.org, Anton Martchukov <anton@martchukov.com>
Cc: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, David S Register <bdbcat@yahoo.com>
Subject: Re: Bug#538067: RFS: opencpn
Date: Sat, 9 Jul 2011 14:57:20 -0700 (PDT)
Anton wrote:
> 1. Since we are using dfsg tarball I think the version
> should include "+dfsg" otherwise my pbuilder fails to find
> the tarball. I have added this to changelog.

+dfsg into version name:
as our build will be bit-for-bit identical to one built from a non-
stripped version of the source (the only difference between the
source tarballs being unused mac/windows dirs), I don't see a
point in adding the +dfsg to the binary package version, it
clutters for no reason. (if pbuilder method has issues, then fix
pbuilder...)

instead of putting the new tarballs in svn, the latest idea is to
put their md5sum in svn and put the tarball at 
  http://pkg-grass.alioth.debian.org/tarballs/
('get_latest_from_git.sh' now updated in svn with details about
that which I hadn't checked in)


> 2. src/nmea0183/* plugins/*/src/nmea0183/* have the
> following:
...
> So it is not clear which license it is under now? If it is
> BSD than which clause version and why GPL header? If it has
> been relicensed to GPL than I am not sure if it is
> possible to do so providing the given statement from author?

We went through this one a couple weeks ago, I believe that Dave
has the answer &/or has been in contact with the author ..


> 3. plugins/grib_pi/src/Grib* plugins/grib_pi/src/Iso*
> plugins/grib_pi/src/ZuFile
> are taken fron ZyGrib and licensed as GPL-3+. Our code is
> GPL-2+ and I think it is not backward compatible. However as
> I understand this item is a plugin, so maybe it is ok, but
> not sure. 

if bundled as a single distribution transparently to the user
it is a single work and just calling a library a plugin does not
get you some magic exemption from the GPL.

IIRC GPL3 for zygrib is a rather new feature, I wonder if the
code was taken before or after that change? If new, I probably
have an old gpl2 tarball of it around somewhere.


> Beside this there are some less hard issues:
> 
> 6. Plugins are still installed to /usr/lib/opencpn
> although empty directory /usr/lib/opencpn_plugins is being
> created.

I will investigate and fix that today.
(I thought I had already taken care of that, maybe I missed
something or the new beta changes in a way I didn't expect)


Also I need to double check the dispersion of the provided docs
after the upstream path change there.


thanks,
Hamish





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Tue, 16 Aug 2011 11:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Tue, 16 Aug 2011 11:33:07 GMT) Full text and rfc822 format available.

Message #109 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-mentors@lists.debian.org
Cc: 538067@bugs.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>
Subject: request for pkg review (ITP #538067)
Date: Tue, 16 Aug 2011 04:31:34 -0700 (PDT)
Hi,

it is been a while since our last review of the OpenCPN
packaging, and the stable release we were working towards
has now shipped. Our .deb packaging efforts await further
instructions.


source tarball:
  http://pkg-grass.alioth.debian.org/tarballs/opencpn_2.5.0+dfsg.orig.tar.gz

debian/ packaging files:
  svn co svn://svn.debian.org/pkg-grass/packages/opencpn/trunk/debian

earlier review+comments can be found in the ITP:
  http://bugs.debian.org/538067


You'll notice our source tarball is labeled dfsg. This is because
there were some included DLLs to help build the MS Windows
version of the program which we didn't need/want for the Linux
build, the source code itself is untouched.

With respect to that, the one unanswered question Anton & myself
had was if the version in debian/changelog needed to exactly
match the filename of the source package? i.e. do we need to
include "dfsg" in the version number?

I would prefer not to as our build is bit-for-bit identical to
the upstream source distribution, and amending the version number
gives the impression that upstream is somehow not DFSG. There
was some talk that pbuilder had issues with the .orig.tar.gz
version number having to match the final binary package number.
Is there a work around? Does there have to be? (I mean do the
debian buildbots care if the source.orig.tar.gz version exactly
matches?)  I am using debuild and don't experience the problem
myself..


thanks,
Hamish




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Tue, 16 Aug 2011 12:30:45 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Tagliamonte <paultag@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Tue, 16 Aug 2011 12:31:30 GMT) Full text and rfc822 format available.

Message #114 received at 538067@bugs.debian.org (full text, mbox):

From: Paul Tagliamonte <paultag@ubuntu.com>
To: Hamish <hamish_b@yahoo.com>
Cc: debian-mentors@lists.debian.org, 538067@bugs.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>
Subject: Re: request for pkg review (ITP #538067)
Date: Tue, 16 Aug 2011 08:28:44 -0400
On Tue, Aug 16, 2011 at 7:31 AM, Hamish <hamish_b@yahoo.com> wrote:
> Hi,
>
> it is been a while since our last review of the OpenCPN
> packaging, and the stable release we were working towards
> has now shipped. Our .deb packaging efforts await further
> instructions.
>
>
> source tarball:
>  http://pkg-grass.alioth.debian.org/tarballs/opencpn_2.5.0+dfsg.orig.tar.gz
>
> debian/ packaging files:
>  svn co svn://svn.debian.org/pkg-grass/packages/opencpn/trunk/debian
>
> earlier review+comments can be found in the ITP:
>  http://bugs.debian.org/538067
>
>
> You'll notice our source tarball is labeled dfsg. This is because
> there were some included DLLs to help build the MS Windows
> version of the program which we didn't need/want for the Linux
> build, the source code itself is untouched.

Is the source included for those DLLS? If so, I'm not convinced you
need to DFSG repack, but someone else can chime in. I don't think just
because upstream uses krufty practices that it should be repacked.
Now, if it had a nonfree issue, and while you're in there you cleaned
it up, I'm sure that'd be fine.

Again, perhaps a DD can chime in. Was the source included for the DLLs?

>
> With respect to that, the one unanswered question Anton & myself
> had was if the version in debian/changelog needed to exactly
> match the filename of the source package? i.e. do we need to
> include "dfsg" in the version number?

Yeah, you do. Lintian should complain if it's wrong. Take a look at
the source to Fluxbox, we have a dfsg repack in place. Here's a
snippit for you:

      fluxbox (1.3.1~dfsg1-2) unstable; urgency=low

>
> I would prefer not to as our build is bit-for-bit identical to
> the upstream source distribution, and amending the version number
> gives the impression that upstream is somehow not DFSG. There

Are they DFSG? Why repack if it's already DFSG?

> was some talk that pbuilder had issues with the .orig.tar.gz
> version number having to match the final binary package number.
> Is there a work around? Does there have to be? (I mean do the
> debian buildbots care if the source.orig.tar.gz version exactly
> matches?)  I am using debuild and don't experience the problem
> myself..
>
>
> thanks,
> Hamish
>
>
> --
> To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/1313494294.19695.YahooMailClassic@web110016.mail.gq1.yahoo.com
>
>



-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Sun, 11 Dec 2011 06:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Sun, 11 Dec 2011 06:51:03 GMT) Full text and rfc822 format available.

Message #119 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: 538067@bugs.debian.org
Cc: debian-mentors@lists.debian.org, Debian GIS Project <debian-gis@lists.debian.org>, Anton Martchukov <anton@martchukov.com>, David S Register <bdbcat@yahoo.com>
Subject: Re: request for pkg review (ITP #538067)
Date: Sat, 10 Dec 2011 22:47:36 -0800 (PST)
Hi,

it's been a while, so a small update:


* Package still sits in DebianGIS svn + webspace, AFAIK ready for upload
& awaiting a sponsor.

cleansed ver. 2.5.0 tarball:
  http://pkg-grass.alioth.debian.org/tarballs/
debian/ packaging rules:
  http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/


* The optional GRIB plugin is GPLv3 while the main package is GPLv2+.
All plugins have now been moved out into their own binary package, which
is only Suggested by debian/control. Thus the two are no longer distributed
as a bundle. AFAIU if the user wants to manually install then manually activate
these plugins that's their business and GPLv2+ vs. GPLv3 issues are not involved.
This solution seemed less invasive than asserting GPLv3 over the entire package.
FWIW the plugin linking is by API calls and an #include'd "plugins.h". The
resulting binaries are created as plugin_foo.so; users may build and install
their own plugins that we don't ship (e.g. the google maps plugin) so
the plugins dir is always created, and left empty if the *-plugins package
was not installed. This may cause Lintian to be grumpy, but otherwise the
correct dir to use for 3rd party plugins is not obvious to the casual user.


* to put "dfsg" in the version number or not?

Hamish wrote:
>> You'll notice our source tarball is labeled dfsg. This is because
>> there were some included DLLs to help build the MS Windows
>> version of the program which we didn't need/want for the Linux
>> build, the source code itself is untouched.

Paul Tagliamonte wrote:
> Is the source included for those DLLS?

No. They are 3rd party; specifically Nullsoft's NSIS installer,
  http://nsis.sourceforge.net/License
and Microsoft's VisualC++ runtime redistributable.

NSIS is permissive FOSS; vcredist is free as in beer.

Without even considering the unused & source-avail-at-sourceforge NSIS,
I'm pretty certain that free-as-in-beer anything is not allowed to be
uploaded within src.tar.gz files, so it needs to be repacked anyway.

so it comes down to a trivial adjustment:
If pbuilder cares that the exact tarball filename matches the version
in the changelog file it is trivial to edit it in & I would leave that
to the DD uploader to adjust or not as they see fit.
For me building with `debuild -i -uc -us -b -j6` there is no issue.


aside: Anyone know the redistribution terms for vcredist_x86.exe ?
MS's download site does not make it obvious and I guess you have to
actually install it to get the EULA. -> Can a GPL'd Windows program
validly ship it as part of the install, or must it be left as a "why
does it fail with Error 14001?" FAQ on the project's homepage?



thanks,
Hamish




Added tag(s) pending. Request was from Anibal Monsalve Salazar <anibal@debian.org> to control@bugs.debian.org. (Wed, 15 Feb 2012 19:06:10 GMT) Full text and rfc822 format available.

Removed tag(s) pending. Request was from Aron Xu <happyaron.xu@gmail.com> to control@bugs.debian.org. (Sun, 19 Feb 2012 17:45:10 GMT) Full text and rfc822 format available.

Forcibly Merged 538067 653601. Request was from Aron Xu <happyaron.xu@gmail.com> to control@bugs.debian.org. (Sun, 19 Feb 2012 17:45:11 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Fri, 04 May 2012 11:37:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Fri, 04 May 2012 11:37:22 GMT) Full text and rfc822 format available.

Message #130 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: 538067@bugs.debian.org
Cc: debian-gis@lists.debian.org
Subject: Fw: Re: RFS: OpenCPN navigation (ITP #538067)
Date: Fri, 4 May 2012 04:33:20 -0700 (PDT)
for those reading along at home..  the package was uploaded to the ftp
masters but they rejected it after finding a number of files missing
copyright headers. That's since been fixed upstream AFA any of us can
tell, and will be in the upcoming 2.6.0 release. The patch is much too big
IMO to go into the 2.5.0 packaging, so I'd rather just have a bit of a
bloated debian/copyright file for the 2.5.0 package.

So we're still sitting at 99% complete :-)



Hamish wrote:
> To: "Francesco P. Lovergine"
> Cc: "Debian GIS Project"
> Date: Sunday, January 29, 2012, 10:56 PM
[...]
> I'll checkin some explanatory DEP-5 debian/copyright
> Comments: and justifications as soon as Alioth comes back online.

(in the end Anton took care of this)
 
> As Anton noted it's never really 100% finished, but pending
> the above ci, I believe it is now in pretty good shape and ready
> to be considered by the ftpmasters.
> 
> 
> thanks,
> Hamish


Anton, any comments on the state of the revised debian/copyright file
in DebianGIS svn? Is there anything known to be outstanding, &/or does
it now pass the automated checkers?


thanks a bunch,
Hamish




Changed Bug title to 'ITP: opencpn -- A Chartplotter and GPS Navigation' from 'ITP: opencpn -- A concise ChartPlotter/Navigator' Request was from bartm@knars.be to control@bugs.debian.org. (Thu, 07 Jun 2012 12:57:41 GMT) Full text and rfc822 format available.

Changed Bug title to 'ITP: opencpn -- A Chartplotter and GPS Navigation Software (written by and for sailors)' from 'ITP: opencpn -- A Chartplotter and GPS Navigation' Request was from Bart Martens <bartm@debian.org> to control@bugs.debian.org. (Thu, 07 Jun 2012 16:27:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Thu, 04 Apr 2013 19:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Thu, 04 Apr 2013 19:39:04 GMT) Full text and rfc822 format available.

Message #139 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: 538067@bugs.debian.org
Subject: Fw: Re: RFS: OpenCPN navigation (ITP #538067)
Date: Thu, 4 Apr 2013 12:36:00 -0700 (PDT)
Hi,

just to note that the 2.5.0 package is essentially ready for
upload AFAICT, just that I couldn't find any DD with the time to
upload it in time for the wheezy freeze. I hope that as soon as
the freeze is thawed this version of the package can be uploaded
as-is, and after that work would begin to repackage the new stable
version (3.2), which introduces OpenGL deps and a few other new
things. aka I don't want to reset the clock to 0 when the last
milestone is 100% complete, I'd like to book that past milestone
while we can, instead of abandoning it.


thanks,
Hamish



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Fri, 19 Apr 2013 12:42:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Fri, 19 Apr 2013 12:42:09 GMT) Full text and rfc822 format available.

Message #144 received at 538067@bugs.debian.org (full text, mbox):

From: Andreas Tille <andreas@an3as.eu>
To: debian-gis@lists.debian.org
Cc: 538067@bugs.debian.org
Subject: Sponsering OpenCPN (Was: OpenStreetMap tile rendering stack in debian-gis)
Date: Fri, 19 Apr 2013 14:38:26 +0200
Hi Hamish,

On Fri, Apr 19, 2013 at 03:10:20AM -0700, Hamish wrote:
> > Do you need a sponsor for your work?
> 
> if you have any spare time, I've been trying to get the finalized
> OpenCPN package sponsored by someone for almost a year.. (ITP# 538067)

Uhmm!  That's a real shame.  My main point behind the Blends concept was
to create teams inside Debian who work together in specific user
interests.  This fact proves somehow my suspicion that this idea is not
fully implemented in Debian GIS.  To stick to my word from regarding
"Sponsering of Blends"  I see that both criterions are fullfilled:

  a) http://svn.debian.org/viewsvn/pkg-grass/packages/opencpn/
  b) http://blends.alioth.debian.org/gis/tasks/workstation#opencpn

and so here I am having a look:

$ uscan --verbose --force-download
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
   opts=dversionmangle=s/\+dfsg// http://sf.net/opencpn/OpenCPN-([\d\.]+)-Source\.tar\.gz
-- Found the following matching hrefs:
     OpenCPN-3.2.0-Source.tar.gz
     OpenCPN-3.0.0-Source.tar.gz
     OpenCPN-2.5.0-Source.tar.gz
     OpenCPN-2.3.1-Source.tar.gz
     OpenCPN-2.3.0-Source.tar.gz
Newest version on remote site is 3.2.0, local version is 2.5.0+dfsg
 (mangled local version number 2.5.0)
 => Forcing download as requested
-- Downloading updated package OpenCPN-3.2.0-Source.tar.gz


I just want to know whether upstream has just moved forward over this
longish (and admittedly frustrating time for you) or whether you
intentionally decided to package 2.5.0.  I would not question the later
because I admit I'm not that deep into GIS to know the differences but
before I go on sponsering I want to make sure I'll grab the right
package.

Moreover you have injected a +dfsg suffix that lets me assume you are
repackaging upstream tarball for some reason.  Usually this is
accompanied by some get-orig-source target in debian/rules to enable
others reproducing this step.  If it is simply about removing some files
you might like to follow the uscan enhancement I proposed[1] which does
simplify this process for the developer and makes it more transparent.

As far as I can see (at least from downloading 3.2.0 source) the "binary
without source" in wxWidgets should be removed.  Reading #538067 log it
seems that the "images without license" issue might be solved - but I
have not yet inspected the tarball deeply.

I also noticed that you have put some MD5SUM files into the tarballs
directory in SVN.  Please note that it is close to impossible to have
MD5SUM identical tarballs when changing anything in a tarball.  (There
was some relevant discussion on debian-devel@l.d.o.)  In other words:
Somebody who re-runs your (to be provided) get-orig-source target will
get a different MD5SUM (even if the untared dirs are byte identical).

In short: If you want your sponsor using the same tarball as you it is
better to provide a link[2] or use mentors.debian.net.  I for myself
(and in Debian Med team in general - Debian GIS might be different)
prefer a recipe who to recreate the tarball.

Regarding your packaging:

debian/rules:

I have read in the log of #538067 you were advised to remove third party
code in

  override_dh_auto_configure:

Just for the record:  I do not fully support this way because the
package will fail to build twice in a row because of the removed files.
So the cleanest way would be to move the files in
override_dh_auto_configure: out of the way and restore them if needed
in override_dh_auto_clean:.  I will not insist on this nitpicking,
just mentioning it.

I noticed your commented flags to enable hardening.  IMHO you could
safe a lot of this stuff by using debhelper compat level 9 which
cares for hardening automatically.

I was able to build the package with no lintian issues (except
hardening) and if you confirm the proper version you want me to sponser
I would have a more detailed look.

> I'd pretty much given up trying until the release freeze was over,
> the fastest option was looking like me going through the DD process
> myself.

I wished people would not have a reason to give up.  Becoming a DM
(first DM than DD) is a good idea anyway. 

Kind regards

         Andreas.

[1] https://wiki.debian.org/UscanEnhancements
[2] http://pkg-grass.alioth.debian.org/tarballs/opencpn_2.5.0+dfsg.orig.tar.gz

-- 
http://fam-tille.de



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Fri, 19 Apr 2013 14:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Fri, 19 Apr 2013 14:06:04 GMT) Full text and rfc822 format available.

Message #149 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-gis@lists.debian.org, Andreas Tille <andreas@an3as.eu>
Cc: 538067@bugs.debian.org
Subject: Re: Sponsering OpenCPN (Was: OpenStreetMap tile rendering stack in debian-gis)
Date: Fri, 19 Apr 2013 07:02:29 -0700 (PDT)
Andreas:
> My main point behind the Blends concept was to create teams
> inside Debian who work together in specific user
> interests.  This fact proves somehow my suspicion that
> this idea is not fully implemented in Debian GIS.

I think the main issue is lack of manpower. Frankie can't
do it all alone. Working on Blends seems like a bonus activity
to me, but there are too many fires to put out and worry about
right now so it doesn't get the attention it might otherwise.
shrug


> and so here I am having a look:
> 
> $ uscan --verbose --force-download
...
> Newest version on remote site is 3.2.0, local version is
> 2.5.0+dfsg
>  (mangled local version number 2.5.0)
>  => Forcing download as requested
> -- Downloading updated package OpenCPN-3.2.0-Source.tar.gz
>
> I just want to know whether upstream has just moved forward
> over this longish (and admittedly frustrating time for you)
> or whether you intentionally decided to package 2.5.0.

2.5.0 was the new stable version which Anton and me focused on
packaging. OpenCPN has had crazy success (check the SourceForge
download stats, it's not VLC but for a niche software it's doing
15k+ downloads a month)
http://sourceforge.net/projects/opencpn/files/opencpn/stats/timeline?dates=2009-04-10+to+2013-04-19

AFAIK the 2.5.0 package we made is pretty much complete and ready
to go. As mentioned in the last messages of the bug report, I'd
like to get 2.5.0 in as the baseline, and then proceed from
there.  2.5.0 was a really good solid release. In fact I'm
still using it as my day-to-day since it 'just works' for
everything I need to do with it.

The newer versions add OpenGL support and other changes which
mean more work, dependencies, etc. I'd like have 2.5.0 as a
solid delta before destabalizing the packaging effort over that.
The "it's ready as-is now" thinking also makes me a bit anxious
to get it reviewed before sid starts moving quickly and there's
external breakage to deal with, resetting the clock to zero,
again.


> before I go on sponsering I want to make sure I'll grab the
> right package.

In the ITP report I provide the link to the dfsg tarball dir
(hosted on was-alioth) and a link to the debian/ packaging rules
(hosted in DebianGIS's svn on was-alioth). I'm still aiming
at the same version.


> Moreover you have injected a +dfsg suffix that lets me
> assume you are repackaging upstream tarball for some reason.

as noted in the ticket, the original tarball had Microsoft's
Visual C++ runtime redistributable DLLs in it. we don't use that
but Debian can't host a source package containing it.
So that and IIRC some Mac OSX specific stuff got removed.


> If it is simply about removing some files you might like to
> follow the uscan enhancement I proposed[1] which does
> simplify this process for the developer and makes it more
> transparent.

ok, will look into it, but a job for tomorrow. :)  (or next week,
I'm just about to jump on a boat)


> As far as I can see (at least from downloading 3.2.0 source)

(I'm still aiming for 2.5.0 for now)

> the "binary without source" in wxWidgets should be removed. 

I'm not sure if that's in the 2.5.0+dfsg tarball I prepared,
I'd be rather surprised if it was. (a public script creates that
the tarball (and the md5sum) the way, I think it's on the alioth
site, somewhere. I'm all about the automation..)

> Reading #538067 log it
> seems that the "images without license" issue might be
> solved - but I have not yet inspected the tarball deeply.

AFAIK all known issues were solved. IIRC the images were by
the author and he was responsive in our copyright cleanup
tasks, fixing many of the issues upstream for the then-next 3.0
release.


> I also noticed that you have put some MD5SUM files into the
> tarballs directory in SVN.
> Please note that it is close to impossible to have MD5SUM
> identical tarballs when changing anything in a tarball.

IIRC, I did that to provide some sort of audit trail for edits
to the md5sums, since the tarball downloads (not in svn) were
in a dir which was writable by many more people, with just
the filesystem stat to know who replaced the file there last.


> In short: If you want your sponsor using the same tarball as
> you it is better to provide a link[2] or
> use mentors.debian.net. 

We did upload it to mentors. Twice. It just sat there. Too
complicated I guess..

> I for myself
> (and in Debian Med team in general - Debian GIS might be
> different) prefer a recipe who to recreate the tarball.

It's there somewhere hiding in plain sight, sorry I'm out of
time now or I'd hunt down the link.


> Regarding your packaging:
> debian/rules:
> I have read in the log of #538067 you were advised to remove
> third party code in
>   override_dh_auto_configure:
> 
> Just for the record:  I do not fully support this way
> because the package will fail to build twice in a row because
> of the removed files.

I'm pretty sure the result was multi-entrant. (was doing many
iterations of testing, and I'm pretty sure I would have made
it so if it was a problem. easy enough to add a if [ -e ..] ; rm)
No time left today to check right now.

> I noticed your commented flags to enable hardening. 
> IMHO you could safe a lot of this stuff by using debhelper
> compat level 9 which cares for hardening automatically.

I'll have a look. The hardening rules came in after we thought
we were ready for upload, so was a last minute addition.


> I was able to build the package with no lintian issues
> (except hardening) and if you confirm the proper version you
> want me to sponser I would have a more detailed look.

(2.5.0, thanks)

 
> > I'd pretty much given up trying until the release freeze was
> > over, the fastest option was looking like me going through
> > the DD process myself.
> 
> I wished people would not have a reason to give up.

that it didn't get a second upload before the wheeze freeze was
a bit sad for us. In all fairness we did get a first upload
and review by the ftp masters who noticed a few problems.


> Becoming a DM (first DM than DD) is a good idea anyway.

whatever works.


regards,
Hamish



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Fri, 19 Apr 2013 14:15:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hamish <hamish_b@yahoo.com>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Fri, 19 Apr 2013 14:15:14 GMT) Full text and rfc822 format available.

Message #154 received at 538067@bugs.debian.org (full text, mbox):

From: Hamish <hamish_b@yahoo.com>
To: debian-gis@lists.debian.org, Andreas Tille <andreas@an3as.eu>
Cc: 538067@bugs.debian.org
Subject: Re: Sponsering OpenCPN (Was: OpenStreetMap tile rendering stack in debian-gis)
Date: Fri, 19 Apr 2013 07:12:09 -0700 (PDT)
Hamish:
> (a public script creates that tarball (and the md5sum) the way,
> I think it's on the alioth site, somewhere. I'm all about the
> automation..)

here'tis, pretty simple:

http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/get_latest_from_git.sh?view=markup


regards,
Hamish



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Fri, 19 Apr 2013 16:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Tille <andreas@an3as.eu>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Fri, 19 Apr 2013 16:24:04 GMT) Full text and rfc822 format available.

Message #159 received at 538067@bugs.debian.org (full text, mbox):

From: Andreas Tille <andreas@an3as.eu>
To: 538067@bugs.debian.org
Cc: debian-gis@lists.debian.org
Subject: Re: Sponsering OpenCPN (Was: OpenStreetMap tile rendering stack in debian-gis)
Date: Fri, 19 Apr 2013 18:18:53 +0200
Hi Hamish,

On Fri, Apr 19, 2013 at 07:02:29AM -0700, Hamish wrote:
> > My main point behind the Blends concept was to create teams
> > inside Debian who work together in specific user
> > interests.  This fact proves somehow my suspicion that
> > this idea is not fully implemented in Debian GIS.
> 
> I think the main issue is lack of manpower.

ACK.

> Frankie can't
> do it all alone.

Fully ACK.  Same was for me in Debian Med so I actively cared for
convincing people to join.  If you want to see some graphs that
show this you might like to compare:

   http://debian-med.debian.net/

   http://blends.debian.net/gis/

In the Debian Med case you notice that the discussion between several
people leads to an increase of people who are doing actual work (VCS
commits, Uploads, bugs closed).  In Debian GIS there is not so much
discussion (explaining, inviting newbies etc.) which leads to the fact
of a very few and actually very busy people.  So because Frankie can
not do it all alone (and I admit he does a great job) people could
assist him in inviting newcomers to increase the team.

> Working on Blends seems like a bonus activity
> to me, but there are too many fires to put out and worry about
> right now so it doesn't get the attention it might otherwise.
> shrug

IMHO the numbers prove you wrong that Blends activities are a bonus but
rather a precondition to attract more people.  I consider Free Software
in medicine as *way* *less* populated than GIS - so if we even succeed
to attract a strong team here - why shouldn't this work for GIS?  Not
caring for the number of people and than using the excuse that you are
only a few people does not sound very logical to me.

> 2.5.0 was the new stable version which Anton and me focused on
> packaging. OpenCPN has had crazy success (check the SourceForge
> download stats, it's not VLC but for a niche software it's doing
> 15k+ downloads a month)
> http://sourceforge.net/projects/opencpn/files/opencpn/stats/timeline?dates=2009-04-10+to+2013-04-19
> 
> AFAIK the 2.5.0 package we made is pretty much complete and ready
> to go. As mentioned in the last messages of the bug report, I'd
> like to get 2.5.0 in as the baseline, and then proceed from
> there.  2.5.0 was a really good solid release. In fact I'm
> still using it as my day-to-day since it 'just works' for
> everything I need to do with it.
> 
> The newer versions add OpenGL support and other changes which
> mean more work, dependencies, etc. I'd like have 2.5.0 as a
> solid delta before destabalizing the packaging effort over that.
> The "it's ready as-is now" thinking also makes me a bit anxious
> to get it reviewed before sid starts moving quickly and there's
> external breakage to deal with, resetting the clock to zero,
> again.

OK, lets stick to 2.5.0 for the moment - perfectly fine for me.
 
> > before I go on sponsering I want to make sure I'll grab the
> > right package.
> 
> In the ITP report I provide the link to the dfsg tarball dir
> (hosted on was-alioth) and a link to the debian/ packaging rules
> (hosted in DebianGIS's svn on was-alioth). I'm still aiming
> at the same version.

I've got the tarball from there.

> > Moreover you have injected a +dfsg suffix that lets me
> > assume you are repackaging upstream tarball for some reason.
> 
> as noted in the ticket, the original tarball had Microsoft's
> Visual C++ runtime redistributable DLLs in it. we don't use that
> but Debian can't host a source package containing it.
> So that and IIRC some Mac OSX specific stuff got removed.

Fine - but just looking at the debian/ dir undocumented.

> > If it is simply about removing some files you might like to
> > follow the uscan enhancement I proposed[1] which does
> > simplify this process for the developer and makes it more
> > transparent.
> 
> ok, will look into it, but a job for tomorrow. :)  (or next week,
> I'm just about to jump on a boat)

Not particularly needed - just a hint to simplify things.

> > As far as I can see (at least from downloading 3.2.0 source)
> 
> (I'm still aiming for 2.5.0 for now)

OK.

> > the "binary without source" in wxWidgets should be removed. 
> 
> I'm not sure if that's in the 2.5.0+dfsg tarball I prepared,
> I'd be rather surprised if it was. (a public script creates that
> the tarball (and the md5sum) the way, I think it's on the alioth
> site, somewhere. I'm all about the automation..)

I've seen the script in SVN you are mentioning in your other mail - but
we shold formalise this *inside* the debian/ dir.  I'm fine if you call
this script inside a get-orig-source target.

> > Reading #538067 log it
> > seems that the "images without license" issue might be
> > solved - but I have not yet inspected the tarball deeply.
> 
> AFAIK all known issues were solved. IIRC the images were by
> the author and he was responsive in our copyright cleanup
> tasks, fixing many of the issues upstream for the then-next 3.0
> release.

OK.
 
> > I also noticed that you have put some MD5SUM files into the
> > tarballs directory in SVN.
> > Please note that it is close to impossible to have MD5SUM
> > identical tarballs when changing anything in a tarball.
> 
> IIRC, I did that to provide some sort of audit trail for edits
> to the md5sums, since the tarball downloads (not in svn) were
> in a dir which was writable by many more people, with just
> the filesystem stat to know who replaced the file there last.

That's why I would like to recreate directly from upstream tarball to
control the download process myself.

> > In short: If you want your sponsor using the same tarball as
> > you it is better to provide a link[2] or
> > use mentors.debian.net. 
> 
> We did upload it to mentors. Twice. It just sat there. Too
> complicated I guess..

OK, did not checked mentors because it was not mentioned in the bug
report.

> > I for myself
> > (and in Debian Med team in general - Debian GIS might be
> > different) prefer a recipe who to recreate the tarball.
> 
> It's there somewhere hiding in plain sight, sorry I'm out of
> time now or I'd hunt down the link.

Just take your time.

> > Regarding your packaging:
> > debian/rules:
> > I have read in the log of #538067 you were advised to remove
> > third party code in
> >   override_dh_auto_configure:
> > 
> > Just for the record:  I do not fully support this way
> > because the package will fail to build twice in a row because
> > of the removed files.
> 
> I'm pretty sure the result was multi-entrant. (was doing many
> iterations of testing, and I'm pretty sure I would have made
> it so if it was a problem. easy enough to add a if [ -e ..] ; rm)
> No time left today to check right now.

Well, it changes the directory content compared to the tarball.  Usually
debuild does not like this.  It is fine with pbuilder who is working on
a copy.

> > I noticed your commented flags to enable hardening. 
> > IMHO you could safe a lot of this stuff by using debhelper
> > compat level 9 which cares for hardening automatically.
> 
> I'll have a look. The hardening rules came in after we thought
> we were ready for upload, so was a last minute addition.

Hardening is no hard criterion for letting me sponsoring.  However,
enabling it if it comes cheap it does not harm.
 
> > I wished people would not have a reason to give up.
> 
> that it didn't get a second upload before the wheeze freeze was
> a bit sad for us. In all fairness we did get a first upload
> and review by the ftp masters who noticed a few problems.

Any link to the rejection mail to verify that we do not bother them
twice with the same problem?
 
> > Becoming a DM (first DM than DD) is a good idea anyway.
> 
> whatever works.

IMHO DM and afterwards DD is the usual procedure.

Kind regards

        Andreas.
 

-- 
http://fam-tille.de



Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Anton Martchukov <anton@martchukov.com>:
Bug#538067; Package wnpp. (Wed, 23 Oct 2013 14:51:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to anarcat <anarcat@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Anton Martchukov <anton@martchukov.com>. (Wed, 23 Oct 2013 14:51:04 GMT) Full text and rfc822 format available.

Message #164 received at 538067@bugs.debian.org (full text, mbox):

From: anarcat <anarcat@debian.org>
To: 538067@bugs.debian.org
Subject: any progress on the opencpn package?
Date: Wed, 23 Oct 2013 10:48:06 -0400
[Message part 1 (text/plain, inline)]
Hello!

I have this package sitting in my "obsolete/locally installed" group in
aptitude, and I am wondering what's going on with the packaging? :)

From what I can see in this bug report, it was just looking for a
sponsor for the upload, which is something I would be happy to do if it
was the only blocker...

Let's get this show on the road!

A.

-- 
Il n'existe aucune limite sacrée ou non à l'action de l'homme dans
l'univers. Depuis nos origines nous avons le choix: être aveuglé par
la vérité ou coudre nos paupières.
                        - [no one is innocent]
[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 10:39:57 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.