Debian Bug report logs - #538067
ITP: opencpn -- Chartplotter and GPS Navigation Software

Toggle useless messages

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

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

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

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)]

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

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)]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)]

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

From: Antoine Beaupré <anarcat@debian.org>

To: Anton Martchukov <anton@martchukov.com>, hamish_b@yahoo.com, debian-gis@lists.debian.org, pabs@debian.org

Cc: 538067@bugs.debian.org

Subject: status of the OpenCPN package?

Date: Sun, 01 Jun 2014 21:05:36 -0400

[Message part 1 (text/plain, inline)]

Hi,

I am writing to you because you have participated in the review of the
new OpenCPN debian package as part of bug #538067.

I would be ready to sponsor the package if people are okay with its
current state. It would be a shame to have the package stalled in that
bug report forever like this. :)

Note that upstream is now at version 3.2.2 as well, so there may be some
work required to get it up to the latest release. Yet i believe that
uploading 2.5 would be better than nothing.

What's blocking this? do you need an uploader?

A.

-- 
Il faut tout un village pour élever un enfant.
                        - Proverbe africain

[Message part 2 (application/pgp-signature, inline)]

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

From: "Francesco P. Lovergine" <frankie@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: Anton Martchukov <anton@martchukov.com>, hamish_b@yahoo.com, debian-gis@lists.debian.org, pabs@debian.org, 538067@bugs.debian.org

Subject: Re: status of the OpenCPN package?

Date: Mon, 23 Jun 2014 23:37:24 +0200

On Sun, Jun 01, 2014 at 09:05:36PM -0400, Antoine Beaupré wrote:
> Hi,
> 
> I am writing to you because you have participated in the review of the
> new OpenCPN debian package as part of bug #538067.
> 
> I would be ready to sponsor the package if people are okay with its
> current state. It would be a shame to have the package stalled in that
> bug report forever like this. :)
> 
> Note that upstream is now at version 3.2.2 as well, so there may be some
> work required to get it up to the latest release. Yet i believe that
> uploading 2.5 would be better than nothing.
> 
> What's blocking this? do you need an uploader?
> 
> A.
> 

I think Hamish_B who worked in the past on this is currently busy, as
happens frequently with Real Life. I'm not sure if anyone is able
to work on that starting from current status.

-- 
Francesco P. Lovergine

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

From: Hamish <hamish_b@yahoo.com>

To: "Francesco P. Lovergine" <frankie@debian.org>, Antoine Beaupré <anarcat@debian.org>

Cc: Anton Martchukov <anton@martchukov.com>, "debian-gis@lists.debian.org" <debian-gis@lists.debian.org>, "pabs@debian.org" <pabs@debian.org>, "538067@bugs.debian.org" <538067@bugs.debian.org>

Subject: Re: status of the OpenCPN package?

Date: Tue, 24 Jun 2014 03:22:53 -0700

Antoine Beaupré wrote:

>>  I am writing to you because you have participated in the review of the
>>  new OpenCPN debian package as part of bug #538067.
>> 
>>  I would be ready to sponsor the package if people are okay with its
>>  current state. It would be a shame to have the package stalled in that
>>  bug report forever like this. :)
>>
>>  Note that upstream is now at version 3.2.2 as well, so there may be some
>>  work required to get it up to the latest release. Yet i believe that
>>  uploading 2.5 would be better than nothing.
>> 
>>  What's blocking this? do you need an uploader?

Francesco:
> I think Hamish_B who worked in the past on this is currently busy, as
> happens frequently with Real Life. I'm not sure if anyone is able
> to work on that starting from current status.

Hi,

indeed I am super busy with other responsibilites right now, but I haven't
given up on this package! There is very little blocking it now, I don't
even remeber what if anything, need to check the last post to the ITP and
the ftp-master's previous rejection comment. :) AFAIR it wasn't anything
major.

I was hesitating to update the packaging in debiangis svn for two reasons,
one was that the 2.5.0 package was 99% ready to go, and a 3.2.2 would
require resetting the QA-clock to zero. So my plan there was to get 2.5.0
into sid immediately then work on 3.2.2 after. The second reason was that
opencpn 3 replaced the graphics canvas with OpenGL, and for Debian/Ubuntu
combined with a Intel GPU it caused a rendering bug for many people. (one
of the main use cases for opencpn is on laptops where intel GPUs are very
common). It's been a while since I checked on the status of the bug, but
I'm thinking that it is still present in 3.2.2? (don't quote me on that :)

Also since for me at least 2.5.0 is basically feature-complete and a very
rock-solid release, I wasn't in a rush for the new nice extra features
like improved AIS and radar overlay. Nice, but not critical to the primary
purpose of the program.

Probably todo is to check if the build is still ok with the latest sid,
since perhaps some package names could need updating in the control file.
But otherwise I am quite confident in the state of the current packaging
and very supportive of one final review before upload. A huge amount of
work went into it, so it would be a real shame to throw it out and start
again, even if a lot of our review is now merged upstream!


thanks for your interest,
Hamish

ps- MB-System is also very close to being ready for final review, the
final 3rd party murky license trouble is now happily resolved with LGPL
since a couple weeks ago. (packaging code for this also in alioth debiangis
svn)

pps- updated gpsdrive too! although I've been maintaining that in the
upstream debian/ dir and need to merge that with alioth, and make one
final mapnik2 api change commit before I tag a new release. RC version
can be tested with ubu 14.04 at dev side of http://live.osgeo.org.

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

From: Antoine Beaupré <anarcat@debian.org>

To: Hamish <hamish_b@yahoo.com>, "Francesco P. Lovergine" <frankie@debian.org>

Cc: Anton Martchukov <anton@martchukov.com>, "debian-gis\@lists.debian.org" <debian-gis@lists.debian.org>, "pabs\@debian.org" <pabs@debian.org>, "538067\@bugs.debian.org" <538067@bugs.debian.org>

Subject: Re: status of the OpenCPN package?

Date: Wed, 13 Aug 2014 19:21:08 -0400

[Message part 1 (text/plain, inline)]

On 2014-06-24 06:22:53, Hamish wrote:
> Antoine Beaupré wrote:
>
>>>  I am writing to you because you have participated in the review of the
>>>  new OpenCPN debian package as part of bug #538067.
>>> 
>>>  I would be ready to sponsor the package if people are okay with its
>>>  current state. It would be a shame to have the package stalled in that
>>>  bug report forever like this. :)
>>>
>>>  Note that upstream is now at version 3.2.2 as well, so there may be some
>>>  work required to get it up to the latest release. Yet i believe that
>>>  uploading 2.5 would be better than nothing.
>>> 
>>>  What's blocking this? do you need an uploader?
>
> Francesco:
>> I think Hamish_B who worked in the past on this is currently busy, as
>> happens frequently with Real Life. I'm not sure if anyone is able
>> to work on that starting from current status.
>
> Hi,
>
> indeed I am super busy with other responsibilites right now, but I haven't
> given up on this package! There is very little blocking it now, I don't
> even remeber what if anything, need to check the last post to the ITP and
> the ftp-master's previous rejection comment. :) AFAIR it wasn't anything
> major.

Alright, I fully understand that. Sharing those comments here would be
quite useful if someone else wants to pursue your work in case you
become too busy in the future. :)

> I was hesitating to update the packaging in debiangis svn for two reasons,
> one was that the 2.5.0 package was 99% ready to go, and a 3.2.2 would
> require resetting the QA-clock to zero. So my plan there was to get 2.5.0
> into sid immediately then work on 3.2.2 after. The second reason was that
> opencpn 3 replaced the graphics canvas with OpenGL, and for Debian/Ubuntu
> combined with a Intel GPU it caused a rendering bug for many people. (one
> of the main use cases for opencpn is on laptops where intel GPUs are very
> common). It's been a while since I checked on the status of the bug, but
> I'm thinking that it is still present in 3.2.2? (don't quote me on that :)

This seems perfectly reasonable - 3.2.2 can be uploaded to experimental
once 2.5 passes NEW.

> Also since for me at least 2.5.0 is basically feature-complete and a very
> rock-solid release, I wasn't in a rush for the new nice extra features
> like improved AIS and radar overlay. Nice, but not critical to the primary
> purpose of the program.

Indeed.

> Probably todo is to check if the build is still ok with the latest sid,
> since perhaps some package names could need updating in the control file.
> But otherwise I am quite confident in the state of the current packaging
> and very supportive of one final review before upload. A huge amount of
> work went into it, so it would be a real shame to throw it out and start
> again, even if a lot of our review is now merged upstream!

of course. keep in mind that the jessie freeze is only a few months
ahead (3, i think?) so if you want OpenCPN to be "in debian" in the next
few years, we should get this show on the road!

thanks for working on this.

a.
-- 
Si l'image donne l'illusion de savoir
C'est que l'adage pretend que pour croire,
L'important ne serait que de voir
                        - Lofofora

[Message part 2 (application/pgp-signature, inline)]

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

From: Andreas Tille <andreas@an3as.eu>

To: debian-gis@lists.debian.org

Cc: Anton Martchukov <anton@martchukov.com>, "pabs@debian.org" <pabs@debian.org>, 538067@bugs.debian.org

Subject: Re: status of the OpenCPN package?

Date: Thu, 14 Aug 2014 08:29:40 +0200

Hi,

On Wed, Aug 13, 2014 at 07:21:08PM -0400, Antoine Beaupré wrote:
> ...
> of course. keep in mind that the jessie freeze is only a few months
> ahead (3, i think?) so if you want OpenCPN to be "in debian" in the next
> few years, we should get this show on the road!

The packaging attempt is a group effort and available in

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

So you are free to commit there (or even move this to Git which is as
far as I know a migration path Debian GIS has agreed upon).  The offer
for sponsering the package from my side stays valid for any team member.
Some hintes what I consider worth changing to the packaging are in the
log of the bug report.

Kind regards

       Andreas.

-- 
http://fam-tille.de

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

From: Hamish <hamish.webmail@gmail.com>

To: Andreas Tille <andreas@an3as.eu>

Cc: debian-gis@lists.debian.org, Anton Martchukov <anton@martchukov.com>, "pabs@debian.org" <pabs@debian.org>, 538067@bugs.debian.org

Subject: Re: status of the OpenCPN package?

Date: Thu, 14 Aug 2014 18:44:55 +1200

Andreas wrote:
> So you are free to commit there (or even move this to Git

As long as I am the acting lead/co-author and maintainer of the
packaging effort I would dearly prefer to keep it in svn, and moreover
have people coordinate with Anton and myself before applying their own
patches, thankyouverymuch. The most important part of working together in a team is communication and mutual respect, not "the last person to commit wins". </pet peeve>


The OSGeo Live DVD ships in the very near future, if anyone wants to
help free my time to work on other things, helping to test that would
be greatly appreciated.  http://aiolos.survey.ntua.gr/gisvm/dev/


patches welcome,
Hamish

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

From: Andreas Tille <andreas@an3as.eu>

To: Hamish <hamish.webmail@gmail.com>

Cc: debian-gis@lists.debian.org, Anton Martchukov <anton@martchukov.com>, "pabs@debian.org" <pabs@debian.org>, 538067@bugs.debian.org

Subject: Re: status of the OpenCPN package?

Date: Thu, 14 Aug 2014 09:18:48 +0200

On Thu, Aug 14, 2014 at 06:44:55PM +1200, Hamish wrote:
> Andreas wrote:
> > So you are free to commit there (or even move this to Git
> 
> As long as I am the acting lead/co-author and maintainer of the

I understood your "no time" flag as rather non-acting.

> packaging effort I would dearly prefer to keep it in svn,

Fine for me, sorry if I suggested something you did not liked.

> and moreover
> have people coordinate with Anton and myself before applying their own
> patches, thankyouverymuch.

What about "our" (in terms of a team) patches?  I wonder why you come up
with the idea of applying "own" patches.  I have addressed some
issues[1] in the packaging which are not addressed since >1 year as far
as I can see and without testing the package should generate several
lintian warnings.  This is plain Debian packaging stuff and IMHO it
would be rather sensible if people who are admitting to have no time
would give people free hands to work on such open issues.  If something
might happen against your intention (you have proven an impressively
quick response time with your current answer) it is quite simple to
revert.

> The most important part of working together in a team is communication and mutual respect, not "the last person to commit wins". </pet peeve>

I understand working in a team that anybody can bring things forward.  I
consider it bad leading if you stop people from working in advance
instead of inspecting their commits and tweak (rewert?) if needed.  Your
lose / win terminology implies a conflict / fight which I fail to see
and my experience has shown that it brings things forward if you
encourage people to do something.

Kind regards

     Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538067#159

-- 
http://fam-tille.de

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

From: Antoine Beaupré <anarcat@debian.org>

To: 538067@bugs.debian.org

Cc: debian-gis@lists.debian.org, Anton Martchukov <anton@martchukov.com>, "pabs\@debian.org" <pabs@debian.org>, Hamish <hamish_b@yahoo.com>, Andreas Tille <andreas@an3as.eu>

Subject: deadline coming soon for OpenCPN

Date: Tue, 30 Sep 2014 23:58:53 -0400

[Message part 1 (text/plain, inline)]

Folks, the Debian Jessie freeze is coming up quickly. I do not think the
question of ownership of the package are productive at this point.

3.2 seems to be upstream's stable release at this point. It would seem
like a bad idea to ship Jessie with 2.x, but if that's all we can
manage, let's do it.

Hamish, you seemed to be saying that the FTP masters rejected a previous
version of the package: what was the reason? Sharing this here will save
everyone (and especially the FTP masters) a lot of time. You were also
mentionning issues about the package mentionned in the "last post in the
ITP", which I assume you mean:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538067#159

I think the major issue that Andreas mentionned there is the
"DFSG-tarball" generation: the script should be in the debian/ directory
so the source can be regenerated easily without requiring access the SVN
repo. The script I could find is this:

http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/get_latest_from_git.sh?view=co&revision=HEAD&content-type=text%2Fplain

.. but that script seems to generate a tarball based on the git
repository, and doesn't seem to checkout any specific tag, so I doubt it
will work unmodified.

There were also issues with the debian/rules targets for repeated
builds.

Andreas, was there other things you were thinking should be fixed with
the package?

Finally, did anyone take a look at that PPA? Why aren't we just using
that debian package??

https://launchpad.net/~opencpn/+archive/ubuntu/opencpn

Thanks for the feedback,

A.

-- 
That's one of the remarkable things about life: it's never so bad that
it can't get worse.
                        - Calvin

[Message part 2 (application/pgp-signature, inline)]

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

From: Antoine Beaupré <anarcat@debian.org>

To: 538067@bugs.debian.org

Cc: debian-gis@lists.debian.org, Anton Martchukov <anton@martchukov.com>, "pabs\@debian.org" <pabs@debian.org>, Hamish <hamish_b@yahoo.com>, Andreas Tille <andreas@an3as.eu>

Subject: Re: deadline coming soon for OpenCPN

Date: Wed, 01 Oct 2014 02:11:17 -0400

[Message part 1 (text/plain, inline)]

I have started a git repo that is just a clone of the SVN repository (it
can work two ways) here:

https://people.debian.org/~anarcat/opencpn.git/

(... because i do not have access to the pkg-grass project - feel free
to add me, i am "anarcat" on alioth.)

So far the only change is to add the following makefile target:

## http://wiki.debian.org/onlyjob/get-orig-source
.PHONY: get-orig-source

DTYPE  = +dfsg
DEBDIR =  $(abspath $(dir $(MAKEFILE_LIST)))
PKG    = $(shell dpkg-parsechangelog -l$(DEBDIR)/changelog --show-field Source)
VER    ?= $(shell dpkg-parsechangelog -l$(DEBDIR)/changelog --show-field Version | sed "s/$(DTYPE).*//")
get-orig-source:
	@echo "I: Downloading $(PKG)_$(VER)..."
	uscan --noconf --verbose --rename --destdir=$(CURDIR) --check-dirname-level=0 --force-download --download-version $(VER) $(DEBDIR)
	@echo "I: Extracting..."
	mkdir $(PKG)-$(VER) \
	&& tar -xf $(PKG)_$(VER).orig.tar.* --directory $(PKG)-$(VER) --strip-components 1 \
	|| $(RM) -r $(PKG)-$(VER)
	@echo "I: Removing known non-DFSG material..."
	cd $(PKG)-$(VER) \
	&& rm -rf .git buildosx buildwin wxWidgets \
	          plugins/grib_pi/src/zlib-1.2.3/ \
	          plugins/grib_pi/src/bzip2/ \
	&& rm -f include/tinyxml.h include/tinystr.h src/tinyxml*.cpp /src/tinystr.cpp

	@echo "I: Repacking..."
	find -L "$(PKG)-$(VER)" -xdev -type f -print | sort \
	| GZIP="-n" tar -czf "$(PKG)_$(VER)$(DTYPE).orig.tar.gz" -T- --owner=root --group=root --mode=a+rX \
	&& $(RM) -r "$(PKG)-$(VER)"

With this I can reproducibly create the +dfsg tarball consistently. This
also cleans up the dh_auto_configure target.

I have also pushed an "experimental" branch to that git repo where I
attempted to port the package to 3.2.2.

After further inspection, I believe there's more work to be done to get
3.2.2 into shape in Debian: there are a lot of shipped binary files
still, lots of which do not have source files (if only the sounds and
images). It is not clear to me if the current 2.5.0 package in SVN fixes
those issues at all.

I *think*, however, that I was able to make the upstream 3.2.2 build
with native tinyxml, wxwidgets and so on without any additionnal patches
or changes. Whether the stuff like wvsdata will work at all is an open
question at this point, however.

Furthermore, my understanding of the licensing issues regarding that
software makes it actually legally possible for me to use the upstream
package at this point, which limits the "scratch an itch" work I will be
willing to do here.

A.

-- 
Rock journalism is people who can't write, interviewing people who can't
talk, in order to provide articles for people who can't read.
                        - Frank Zappa

[Message part 2 (application/pgp-signature, inline)]

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

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Antoine Beaupré <anarcat@debian.org>, 538067@bugs.debian.org

Cc: debian-gis@lists.debian.org, Anton Martchukov <anton@martchukov.com>, "pabs@debian.org" <pabs@debian.org>, Hamish <hamish_b@yahoo.com>, Andreas Tille <andreas@an3as.eu>

Subject: Re: deadline coming soon for OpenCPN

Date: Wed, 01 Oct 2014 08:17:31 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/01/2014 08:11 AM, Antoine Beaupré wrote:
> I have started a git repo that is just a clone of the SVN
> repository (it can work two ways) here:
> 
> https://people.debian.org/~anarcat/opencpn.git/
> 
> (... because i do not have access to the pkg-grass project - feel
> free to add me, i am "anarcat" on alioth.)

You're a DD, so you should already have access to the pkg-grass
project on Alioth.

Kind Regards,

Bas

- -- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJUK5x7AAoJEGdQ8QrojUrxvCUP/2kC0jstpRqyOG/Bm/r1lDq5
eLS2Dqrw4Okt8Ts6FbgcHxpB65FN9gkeuJUuqTOe35Rg60sKtrNshL9lwYsQbCiG
RjUnWPHPZrH2YblOLC6iJAk1sZZSyH6hGCXmeqgQczkVRurXzdfnV16Yxt1wMFto
4ibwJoQ8LJymvIJRjwj+ub01BPx825Vrl7ZYDNQJ0dsZX9trwXpBEDYuepWbdkJ6
vB+GxA8Sj+j000wJccgUu1AeAnlgK9MC9sLO9C4JxRRTJJFPebNUjyoWGTI+Ahh9
mS7ZMo/e+wRbillBbtzItuCqOaHQ86deOQ6SMsqiQ3aL6haL+t5P9hfIs3bW5mGB
RisCz1fBgkLZCHH61wHgsc2GtPtb4s757s1ymBMvBRvP4ctyq+Exywdx03QebfZI
6KL6TcLE1IkX/PmRGwk6AC6yHPsScnqTk52qgK4rnN2jlyfgPxpBzYuFwm92BQOH
5UZv7cGR1TTr9QaeRVsHVylHCBKzxenNgdqQVrg3FsxMoA3ytp6xT3LqN4ssJxoY
KVCZ/IhvK0/nunvsjKP2cEyWu+HOa7fbbUvP7R+tqXxdplbAhV3fZSUCFvBbEXm1
h4fGLfVqgHREp1KP3cOQgMpFbs8bYF3bZGCOdvPHMAuVqonK9jffVECtFXB3wSrP
IEXOYz7gUyb6sSEsIEsq
=YTn5
-----END PGP SIGNATURE-----

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

From: Andreas Tille <tille@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: 538067@bugs.debian.org, debian-gis@lists.debian.org, Anton Martchukov <anton@martchukov.com>, "pabs@debian.org" <pabs@debian.org>, Hamish <hamish_b@yahoo.com>

Subject: Re: deadline coming soon for OpenCPN

Date: Wed, 1 Oct 2014 08:36:24 +0200

Hi Antoine,

On Tue, Sep 30, 2014 at 11:58:53PM -0400, Antoine Beaupré wrote:
> Folks, the Debian Jessie freeze is coming up quickly. I do not think the
> question of ownership of the package are productive at this point.
> 
> 3.2 seems to be upstream's stable release at this point. It would seem
> like a bad idea to ship Jessie with 2.x, but if that's all we can
> manage, let's do it.

+1
Thanks for your action on this package.

> Hamish, you seemed to be saying that the FTP masters rejected a previous
> version of the package: what was the reason? Sharing this here will save
> everyone (and especially the FTP masters) a lot of time. You were also
> mentionning issues about the package mentionned in the "last post in the
> ITP", which I assume you mean:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538067#159
> 
> I think the major issue that Andreas mentionned there is the
> "DFSG-tarball" generation: the script should be in the debian/ directory
> so the source can be regenerated easily without requiring access the SVN
> repo. The script I could find is this:
> 
> http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/get_latest_from_git.sh?view=co&revision=HEAD&content-type=text%2Fplain
> 
> .. but that script seems to generate a tarball based on the git
> repository, and doesn't seem to checkout any specific tag, so I doubt it
> will work unmodified.

The latest trunk of

  Vcs-Svn: svn://svn.debian.org/svn/pkg-grass/packages/opencpn/trunk/

has:

$ uscan --verbose --report
-- 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:
     /watch/sf.php/opencpn/OpenCPN-3.2.2-Source.tar.gz (3.2.2)
     /watch/sf.php/opencpn/OpenCPN-3.2.0-Source.tar.gz (3.2.0)
     /watch/sf.php/opencpn/OpenCPN-3.0.0-Source.tar.gz (3.0.0)
     /watch/sf.php/opencpn/OpenCPN-2.5.0-Source.tar.gz (2.5.0)
     /watch/sf.php/opencpn/OpenCPN-2.3.1-Source.tar.gz (2.3.1)
     /watch/sf.php/opencpn/OpenCPN-2.3.0-Source.tar.gz (2.3.0)
Newest version on remote site is 3.2.2, local version is 2.5.0+dfsg
 (mangled local version number 2.5.0)
 => Newer version available from
    https://qa.debian.org/watch/sf.php/opencpn/OpenCPN-3.2.2-Source.tar.gz
-- Scan finished

I admit the request for sponsoring was sooooo long ago that I do not
remember and I see no value to think about aged code.  I'd perfectly
agree if the current source for 3.2.2 would be used for packaging.  I'd
recommend to use Files-Excluded if any files need to be stripped from
this source tarball (but I did not inspected it regarding this issue).

> There were also issues with the debian/rules targets for repeated
> builds.
> 
> Andreas, was there other things you were thinking should be fixed with
> the package?

Since there are several upstream releases inbetween I would need to have
another look.  Since you obviously had a more recent look and you do
not need a sponsor I'd trust your insight if you say it is OK.

> Finally, did anyone take a look at that PPA? Why aren't we just using
> that debian package??
> 
> https://launchpad.net/~opencpn/+archive/ubuntu/opencpn

I personally did not.  The only thing I could say that it always heats
my temper a bit if I learn about another instance of failed
communication between people working on free GIS software.  I wonder
why we are not able to catch all those people into our common project
and do not reinvent the wheel over and over. :-(
 
> Thanks for the feedback,

As you asked for in your other mail I added you to pkg-grass on alioth
(even if Bas mentioned that this is not really needed for DDs).  Since
you seem to be Git affine I would suggest the following:  Either convert
the current

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

to Git or create a new Git repository which is compliant to Debian GIS
policy[1] (fetch the tarball via uscan and use
   git import-orig --pristine-tar
to inject the source.  Designe the debian/ dir according to your insight
as a DD (may be ask for review here - but I'm no GIS expert and thus I
can only check packaging details).  Please also get the person
responsible fpr the PPA involved and invite him to join the project
offering him cooperation to work on this repository.  This should
support his goal to make OpenCPN available in Ubuntu way better than
some random PPA.

Kind regards and thanks again for your push on this

       Andreas.

[1] http://pkg-grass.alioth.debian.org/policy/

-- 
http://fam-tille.de

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

From: Antoine Beaupré <anarcat@debian.org>

To: Andreas Tille <tille@debian.org>

Cc: 538067@bugs.debian.org, debian-gis@lists.debian.org, Anton Martchukov <anton@martchukov.com>, "pabs\@debian.org" <pabs@debian.org>, Hamish <hamish_b@yahoo.com>

Subject: Re: deadline coming soon for OpenCPN

Date: Wed, 01 Oct 2014 09:35:39 -0400

[Message part 1 (text/plain, inline)]

On 2014-10-01 02:36:24, Andreas Tille wrote:
> Hi Antoine,
>
> On Tue, Sep 30, 2014 at 11:58:53PM -0400, Antoine Beaupré wrote:
>> I think the major issue that Andreas mentionned there is the
>> "DFSG-tarball" generation: the script should be in the debian/ directory
>> so the source can be regenerated easily without requiring access the SVN
>> repo. The script I could find is this:
>> 
>> http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/tarballs/get_latest_from_git.sh?view=co&revision=HEAD&content-type=text%2Fplain
>> 
>> .. but that script seems to generate a tarball based on the git
>> repository, and doesn't seem to checkout any specific tag, so I doubt it
>> will work unmodified.

[...]

> I admit the request for sponsoring was sooooo long ago that I do not
> remember and I see no value to think about aged code.  I'd perfectly
> agree if the current source for 3.2.2 would be used for packaging.  I'd
> recommend to use Files-Excluded if any files need to be stripped from
> this source tarball (but I did not inspected it regarding this issue).

I'm not familiar with this mechanism - but it certainly looks
interesting!

https://wiki.debian.org/UscanEnhancements

Am I correct in understanding this would only simplify the
get-orig-source target, not replace it?

>> There were also issues with the debian/rules targets for repeated
>> builds.
>> 
>> Andreas, was there other things you were thinking should be fixed with
>> the package?
>
> Since there are several upstream releases inbetween I would need to have
> another look.  Since you obviously had a more recent look and you do
> not need a sponsor I'd trust your insight if you say it is OK.

I don't think it's okay - it doesn't even build at that stage,
especially because we strip so much off the tarball.

>> Finally, did anyone take a look at that PPA? Why aren't we just using
>> that debian package??
>> 
>> https://launchpad.net/~opencpn/+archive/ubuntu/opencpn
>
> I personally did not.  The only thing I could say that it always heats
> my temper a bit if I learn about another instance of failed
> communication between people working on free GIS software.  I wonder
> why we are not able to catch all those people into our common project
> and do not reinvent the wheel over and over. :-(

The PPA is from upstream, and is fairly minimal: it doesn't split the
code in multiple packages (though I'm not sure why *we* do that in the
first place) and doesn't attempt to deduplicate code.

>> Thanks for the feedback,
>
> As you asked for in your other mail I added you to pkg-grass on alioth
> (even if Bas mentioned that this is not really needed for DDs).  Since
> you seem to be Git affine I would suggest the following:  Either convert
> the current
>
>    svn://svn.debian.org/svn/pkg-grass/packages/opencpn/trunk/
>
> to Git or create a new Git repository which is compliant to Debian GIS
> policy[1] (fetch the tarball via uscan and use
>    git import-orig --pristine-tar
> to inject the source.

Ugh.. pristine-tar... Why do we need this if we're going to strip out
half the tarball anyways?

> Designe the debian/ dir according to your insight
> as a DD (may be ask for review here - but I'm no GIS expert and thus I
> can only check packaging details). 

Well, I'm not sure I'll have much more time to fight for this one - it's
a huge mess, that upstream, in terms of licensing and binary data...

> Please also get the person responsible fpr the PPA involved and invite
> him to join the project offering him cooperation to work on this
> repository.  This should support his goal to make OpenCPN available in
> Ubuntu way better than some random PPA.

It's not exactly a random PPA: it's upstream running their own official
PPA... 

A.

-- 
"Faith" means not wanting to know what is true.
                         - Friedrich Nietzshe

[Message part 2 (application/pgp-signature, inline)]

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

From: Pavel Kalian <pavel@kalian.cz>

To: 538067@bugs.debian.org

Subject: Re: deadline coming soon for OpenCPN

Date: Wed, 07 Jan 2015 20:52:55 -0600

Hi...
I'm an upstream developer and managing the PPA on Launchpad.
It certainly is more messy than needs to be, but it serves it's purpose,
which is to get the packages to the user in a way he can digest...
With the upcoming 4.0 release I have modularized the packages to certain
extent, separating the docs, tide data and GSHHS shorelines as they are
logical components.
I currently do no effort to clean the .orig sources off stuff not needed
on Linux, but it is on my list past the release.
We've put some effort into clarifying the license info etc. over time to
make packaging for Debian possible, but without further feedback from
you, finishing it in an acceptable way will keep having low priority -
we simply lack manpower to study the requirements in-depth.

Thanks for trying to clean up our mess

Pavel

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

From: anarcat <anarcat@debian.org>

To: Pavel Kalian <pavel@kalian.cz>, 538067@bugs.debian.org

Cc: debian-gis@lists.debian.org, pabs@debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: status of the opencpn PPA for inclusion in Debian

Date: Sat, 21 Mar 2015 09:47:23 -0400

[Message part 1 (text/plain, inline)]

On Wed, Jan 07, 2015 at 08:52:55PM -0600, Pavel Kalian wrote:
> Hi...

Hi Pavel,

> I'm an upstream developer and managing the PPA on Launchpad.

Thanks for chiming in! It's certainly a good way to try to resolve this
in the long run. :)

(and sorry for the delay, i wasn't in cc to the bug report so i didn't
see you reply until today.)

> It certainly is more messy than needs to be, but it serves it's purpose,
> which is to get the packages to the user in a way he can digest...

Yeah, and I can certainly appreciate that! I certainly appreciate
instructions on how to use this in jessie, for example. :)

For the record, on Jessie, i am able to install the package from the
Trusty PPA here:

deb http://ppa.launchpad.net/opencpn/opencpn/ubuntu trusty main

I do need to install wxwidgets from sid however, as mentionned in the
upstream instructions.

I would have been able to install the wxwidgets packages from wheezy
(which seems like a better option than sid IMHO) if the dependencies
were a little more relaxed (>= 2.8.12.1 instead of >= 2.8.12.1+dfsg).
Unless of course that's an actual hard dependency requirement.

> With the upcoming 4.0 release I have modularized the packages to certain
> extent, separating the docs, tide data and GSHHS shorelines as they are
> logical components.

That's great news. I haven't reviewed the result but that seems like a
huge improvement already.

> I currently do no effort to clean the .orig sources off stuff not needed
> on Linux, but it is on my list past the release.

Frankly, I don't think it's that critical. The most important point
right now is to ensure there are sources for all the binaries provided
with the package.

Code deduplication is a "should", not a "must" in Debian, IIRC,
especially if there are actually no other copies!

> We've put some effort into clarifying the license info etc. over time to
> make packaging for Debian possible, but without further feedback from
> you, finishing it in an acceptable way will keep having low priority -
> we simply lack manpower to study the requirements in-depth.

Understood. That seems perfectly reasonable. From what I understand,
most of the actual licensing issues are gone. According to a quick
review I did in october, all that was necessary was to remove copies of
wxwidgets, the .git directory, zlib, bzip and tinyxml. I believe those
were probably all "convenience copies of code" (ch. 4.13 in the debian
policy):

http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

So creating a tarball without those *should* be done, but it's not
absolutely necessary, unless there are still (for example) DLLs without
source. What is necessary however is the built package
should *not* use the convenience copies but link to the existing
libraries, to make security upgrades easy and (basically) possible.

Another nice thing would be to build against wxwidgets 3.0: is that
possible at all? A quick search led me to believe it is how opencpn is
compiled in Windows and OSX... Since jessie doesn't ship with 2.8
anymore (for reasons I cannot fathom), compiling against 3.0 means it
would be possible to backport to jessie and even, in fact, all the way
back to wheezy and squeeze, since those also have wxwidget 3.0
backports!

> Thanks for trying to clean up our mess

Well, to be fair, it's an amazing work you guys are doing. I'm just
sitting on the sidelines ranting that my computer isn't working the way
it should be. Sorry about that. :)

I hope my feedback here still has some use, and certainly hope to see
opencpn land in Debian at some point.

And to be real clear, I would be happy to sponsor your package once it:

 1. doesn't compile against convenience copies
 2. doesn't ship binaries without source
 3. builds against 3.x (optional)
 4. doesn't ship convenience copies of code (optional)
 
Do you think the current package fits those requirements?

In fact, I will need this package running in production fairly soon, so
it would make sense for me to push again in that direction. :)

Sorry we missed jessie. We can still make it to backports though. ;)

Hold fast,

A.

[signature.asc (application/pgp-signature, inline)]

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

From: Pavel Kalian <pavel@kalian.cz>

To: anarcat <anarcat@debian.org>, 538067@bugs.debian.org

Cc: debian-gis@lists.debian.org, pabs@debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sat, 21 Mar 2015 11:42:51 -0600

Hi...

On 03/21/2015 07:47 AM, anarcat wrote:
> On Wed, Jan 07, 2015 at 08:52:55PM -0600, Pavel Kalian wrote:
>> Hi...
> Hi Pavel,
>
>> I'm an upstream developer and managing the PPA on Launchpad.
> Thanks for chiming in! It's certainly a good way to try to resolve this
> in the long run. :)
>
> (and sorry for the delay, i wasn't in cc to the bug report so i didn't
> see you reply until today.)
No problem, I've had other funny stuff to do ;)
>
>> It certainly is more messy than needs to be, but it serves it's purpose,
>> which is to get the packages to the user in a way he can digest...
> Yeah, and I can certainly appreciate that! I certainly appreciate
> instructions on how to use this in jessie, for example. :)
>
> For the record, on Jessie, i am able to install the package from the
> Trusty PPA here:
>
> deb http://ppa.launchpad.net/opencpn/opencpn/ubuntu trusty main
>
> I do need to install wxwidgets from sid however, as mentionned in the
> upstream instructions.
>
> I would have been able to install the wxwidgets packages from wheezy
> (which seems like a better option than sid IMHO) if the dependencies
> were a little more relaxed (>= 2.8.12.1 instead of >= 2.8.12.1+dfsg).
> Unless of course that's an actual hard dependency requirement.
Well, that's the feature of Launchpad - it injects the dependency
version for the target Ubuntu release and does not honor what we define
in the control file. Maybe it can be overriden if we specify an exact
version there, but I'm not sure. Will try.
Anyway, as a Testing user myself, removing wx2.8 surprised me "a bit"...
>> With the upcoming 4.0 release I have modularized the packages to certain
>> extent, separating the docs, tide data and GSHHS shorelines as they are
>> logical components.
> That's great news. I haven't reviewed the result but that seems like a
> huge improvement already.
>
>> I currently do no effort to clean the .orig sources off stuff not needed
>> on Linux, but it is on my list past the release.
> Frankly, I don't think it's that critical. The most important point
> right now is to ensure there are sources for all the binaries provided
> with the package.
There are no library binaries involved in Linux build/packaging in the
source tree at all.
The wx DLLs in the tree are not used in the build at all, they are just
convenience for packaging on Windows.
The only binary lib used in any build is the Windows crashreporter - is
it a problem for Debian packaging when it is not at all involved? If it
is, we can of course bundle the source, but it will just mean more
completely unused stuff in the tree.
> Code deduplication is a "should", not a "must" in Debian, IIRC,
> especially if there are actually no other copies!
>
>> We've put some effort into clarifying the license info etc. over time to
>> make packaging for Debian possible, but without further feedback from
>> you, finishing it in an acceptable way will keep having low priority -
>> we simply lack manpower to study the requirements in-depth.
> Understood. That seems perfectly reasonable. From what I understand,
> most of the actual licensing issues are gone. According to a quick
> review I did in october, all that was necessary was to remove copies of
> wxwidgets, the .git directory, zlib, bzip and tinyxml. I believe those
> were probably all "convenience copies of code" (ch. 4.13 in the debian
> policy):
>
> http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
>
> So creating a tarball without those *should* be done, but it's not
> absolutely necessary, unless there are still (for example) DLLs without
> source. What is necessary however is the built package
> should *not* use the convenience copies but link to the existing
> libraries, to make security upgrades easy and (basically) possible.
The bundled libs are not used in Linux build at all, we link against the
system libs. But they are obviously required on Windows. For the
packaging purposes, they can be stripped if it makes sense.
> Another nice thing would be to build against wxwidgets 3.0: is that
> possible at all? A quick search led me to believe it is how opencpn is
> compiled in Windows and OSX... Since jessie doesn't ship with 2.8
> anymore (for reasons I cannot fathom), compiling against 3.0 means it
> would be possible to backport to jessie and even, in fact, all the way
> back to wheezy and squeeze, since those also have wxwidget 3.0
> backports!
It is possible to build against wx3.0 on all platforms (We currently
build against it just for OS X and Android, where it is inevitable,
though). There is a problem with the complete switch - wx3.0 has no
backport for Ubuntu Precise as far as I can tell, neither in the
official repos nor anywhere on Launchpad, which means we would have to
provide our own backport in the PPA or make the users install from
elsewhere, which is quite a PITA and would generate way more support
traffic than living with the  Jessie "problem" for now.
It would also mean rebuilding all the plugins. Quite some work. Said
that, we would like to migrate to wx3, but not with the current 4.0
release (as it looks now, there will most likely be just one maintenance
release in this cycle with a couple of minor fixes). 4.2, out in ~6
months is the target for now.
>> Thanks for trying to clean up our mess
> Well, to be fair, it's an amazing work you guys are doing. I'm just
> sitting on the sidelines ranting that my computer isn't working the way
> it should be. Sorry about that. :)
>
> I hope my feedback here still has some use, and certainly hope to see
> opencpn land in Debian at some point.
>
> And to be real clear, I would be happy to sponsor your package once it:
>
>  1. doesn't compile against convenience copies
As far as I can tell this is addressed for a long time already. For the
build on Unix platforms where the libs are available and cmake can find
them.
>  2. doesn't ship binaries without source
Is the windows-only crashrpt library a problem here? If so, we of course
can include the source. Or can we just link to
http://crashrpt.sourceforge.net/docs/html/index.html in the docs?
Do we have to provide wxWidgets source just because we have to ship the
libraries on Windows and Mac?
Anyway, all of it can be stripped from the tree for packaging on Linux
>  3. builds against 3.x (optional)
It does, but for the reason mentioned above we are not using it on Linux
and Win yet.
>  4. doesn't ship convenience copies of code (optional)
It is needed only to build on Windows, so we can easily strip it from
the source tarball used to create the packages.
>  
> Do you think the current package fits those requirements?
I will implement the stripping of all the Linux-irrelevant stuff in
https://github.com/nohal/launchpad/blob/master/publish.sh so we have a
baseline to finish it off.
>
> In fact, I will need this package running in production fairly soon, so
> it would make sense for me to push again in that direction. :)
>
> Sorry we missed jessie. We can still make it to backports though. ;)
>
> Hold fast,
>
> A.
Pavel

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

From: Antoine Beaupré <anarcat@debian.org>

To: Pavel Kalian <pavel@kalian.cz>, 538067@bugs.debian.org

Cc: debian-gis@lists.debian.org, pabs@debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sat, 21 Mar 2015 15:45:54 -0400

On 2015-03-21 13:42:51, Pavel Kalian wrote:
> On 03/21/2015 07:47 AM, anarcat wrote:
>> On Wed, Jan 07, 2015 at 08:52:55PM -0600, Pavel Kalian wrote:

[...]

>> I would have been able to install the wxwidgets packages from wheezy
>> (which seems like a better option than sid IMHO) if the dependencies
>> were a little more relaxed (>= 2.8.12.1 instead of >= 2.8.12.1+dfsg).
>> Unless of course that's an actual hard dependency requirement.
> Well, that's the feature of Launchpad - it injects the dependency
> version for the target Ubuntu release and does not honor what we define
> in the control file. Maybe it can be overriden if we specify an exact
> version there, but I'm not sure. Will try.

I see, well in this case: don't worry about it, we'll fix this when we
upload to sid anyways.

> Anyway, as a Testing user myself, removing wx2.8 surprised me "a bit"...

Yeah, that's weird. I haven't investigated why it happened...

[...]

>>> I currently do no effort to clean the .orig sources off stuff not needed
>>> on Linux, but it is on my list past the release.
>> Frankly, I don't think it's that critical. The most important point
>> right now is to ensure there are sources for all the binaries provided
>> with the package.
> There are no library binaries involved in Linux build/packaging in the
> source tree at all.
> The wx DLLs in the tree are not used in the build at all, they are just
> convenience for packaging on Windows.
> The only binary lib used in any build is the Windows crashreporter - is
> it a problem for Debian packaging when it is not at all involved? If it
> is, we can of course bundle the source, but it will just mean more
> completely unused stuff in the tree.

Source-less files will be a problem for the FTP masters, that is
certain. We will need to either remove the binary files or include the
source.

[...]

> The bundled libs are not used in Linux build at all, we link against the
> system libs. But they are obviously required on Windows. For the
> packaging purposes, they can be stripped if it makes sense.

They need to be stripped if no source is provided, for sure.

[...]

> It is possible to build against wx3.0 on all platforms (We currently
> build against it just for OS X and Android, where it is inevitable,
> though). There is a problem with the complete switch - wx3.0 has no
> backport for Ubuntu Precise as far as I can tell, neither in the
> official repos nor anywhere on Launchpad, which means we would have to
> provide our own backport in the PPA or make the users install from
> elsewhere, which is quite a PITA and would generate way more support
> traffic than living with the  Jessie "problem" for now.

Maybe we can have the two packages diverge (between ubuntu and Debian)
at that level. Eventually, those differences would go away as 3.0 gets
propagated everywhere...

> It would also mean rebuilding all the plugins. Quite some work. Said
> that, we would like to migrate to wx3, but not with the current 4.0
> release (as it looks now, there will most likely be just one maintenance
> release in this cycle with a couple of minor fixes). 4.2, out in ~6
> months is the target for now.

Understood. However, if 4.0 can be built against 3.x right now, we could
just upload that in Debian without changing things upstream... It would
be easy enough, from what I understand, just a tiny patch to change
dependencies on the control file maybe?

[...]

>> And to be real clear, I would be happy to sponsor your package once it:
>>
>>  1. doesn't compile against convenience copies
> As far as I can tell this is addressed for a long time already. For the
> build on Unix platforms where the libs are available and cmake can find
> them.

Awesome. The debian/control build-dependencies should handle that.

>>  2. doesn't ship binaries without source
> Is the windows-only crashrpt library a problem here? If so, we of course
> can include the source. Or can we just link to
> http://crashrpt.sourceforge.net/docs/html/index.html in the docs?
> Do we have to provide wxWidgets source just because we have to ship the
> libraries on Windows and Mac?
> Anyway, all of it can be stripped from the tree for packaging on Linux

I am not sure. Maybe other DDs (in CC) can provide feedback here, but I
would recommend providing a smaller tarball with only the OpenCPN source
code. First it takes up less space on all the mirrors, and second it
will make the FTP master's job easier.

But my gut feeling is that binaries without source *will* be a problem,
even if the software is free (like say wxWidgets).

[...]

>> Do you think the current package fits those requirements?
> I will implement the stripping of all the Linux-irrelevant stuff in
> https://github.com/nohal/launchpad/blob/master/publish.sh so we have a
> baseline to finish it off.

It would be great to see this as part of the debian package
directly. Earlier in this bug report, I have made a "get-orig-source"
target in debian/rules for exactly that purpose. This is common practice
that should be followed here - although it may conflict with the
multi-source-package approach that seems to have been taken...

Nevertheless, it is important (but not compulsory) that the tools to
build the tarballs from upstream are available or at least referenced in
the source. A common place to document this is debian/README.source.

(Sorry if i'm stating the obvious.)

I am really glad to hear your feedback so quickly, things are looking
pretty bright for getting OpenCPN in Debian.

I believe the next step is to produce a tarball without sourceless
binaries (or with the sourceless binaries's source ;).

Thanks again!

A.
-- 
We should act only in such away that if everyone 
else acted as we do, we would accept the results.
                        - Kant

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

From: Paul Wise <pabs@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: Pavel Kalian <pavel@kalian.cz>, 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sun, 22 Mar 2015 08:38:58 +0800

[Message part 1 (text/plain, inline)]

On Sat, 2015-03-21 at 15:45 -0400, Antoine Beaupré wrote:

> Yeah, that's weird. I haven't investigated why it happened...

https://packages.qa.debian.org/w/wxwidgets2.8.html
https://packages.qa.debian.org/w/wxwidgets2.8/news/20141021T163919Z.html
https://bugs.debian.org/748169
https://bugs.debian.org/762062

> Maybe we can have the two packages diverge (between ubuntu and Debian)
> at that level. Eventually, those differences would go away as 3.0 gets
> propagated everywhere...

Maybe with some macros and ifdefs you could default to wx 3.0 but allow
compiling with wx 2.8?

> I am not sure. Maybe other DDs (in CC) can provide feedback here, but I
> would recommend providing a smaller tarball with only the OpenCPN source
> code. First it takes up less space on all the mirrors, and second it
> will make the FTP master's job easier.
> 
> But my gut feeling is that binaries without source *will* be a problem,
> even if the software is free (like say wxWidgets).

Yes, that will be a problem. I would suggest doing this:

Strip all the binaries and embedded code/data copies from your VCS
repository (git/svn/cvs/etc).

Automate the source tarball build process with the `make distcheck`
target of autotools/cmake etc and just create a source tarball
(opencpn-1.0.tar.xz) with no binaries or embedded code/data copies.

Automate the Windows build process and have it download the requisite
binaries at build time. Or if you prefer a Windows build without network
build access, create a script to download the Windows binaries and put
those in an opencpn-win32-dev.zip file that people can just unzip in the
right place before starting the build. If a second unzip step is too
much for people, you could produce a source tarball for the Linux
distros and a source tarball with all the binaries for Windows folks.
Personally I think Windows users probably don't want the source, they
would just want the compiled binaries.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[signature.asc (application/pgp-signature, inline)]

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

From: Antoine Beaupré <anarcat@debian.org>

To: Paul Wise <pabs@debian.org>

Cc: Pavel Kalian <pavel@kalian.cz>, 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sat, 21 Mar 2015 21:18:48 -0400

On 2015-03-21 20:38:58, Paul Wise wrote:
> On Sat, 2015-03-21 at 15:45 -0400, Antoine Beaupré wrote:
>
>> Yeah, that's weird. I haven't investigated why it happened...
>
> https://packages.qa.debian.org/w/wxwidgets2.8.html
> https://packages.qa.debian.org/w/wxwidgets2.8/news/20141021T163919Z.html
> https://bugs.debian.org/748169
> https://bugs.debian.org/762062

Makes sense.

TLDR; 2.8 was deliberately removed from jessie and is being kept from
entering back because it is unmaintained upstream. I guess the remaining
question is why it's even still in sid. :)

>> Maybe we can have the two packages diverge (between ubuntu and Debian)
>> at that level. Eventually, those differences would go away as 3.0 gets
>> propagated everywhere...
>
> Maybe with some macros and ifdefs you could default to wx 3.0 but allow
> compiling with wx 2.8?

From what I understand, it can easily be built against 3.0 already. It
may even autodetect whatever is there already.

>> I am not sure. Maybe other DDs (in CC) can provide feedback here, but I
>> would recommend providing a smaller tarball with only the OpenCPN source
>> code. First it takes up less space on all the mirrors, and second it
>> will make the FTP master's job easier.
>> 
>> But my gut feeling is that binaries without source *will* be a problem,
>> even if the software is free (like say wxWidgets).
>
> Yes, that will be a problem. I would suggest doing this:
>
> Strip all the binaries and embedded code/data copies from your VCS
> repository (git/svn/cvs/etc).
>
> Automate the source tarball build process with the `make distcheck`
> target of autotools/cmake etc and just create a source tarball
> (opencpn-1.0.tar.xz) with no binaries or embedded code/data copies.
>
> Automate the Windows build process and have it download the requisite
> binaries at build time. Or if you prefer a Windows build without network
> build access, create a script to download the Windows binaries and put
> those in an opencpn-win32-dev.zip file that people can just unzip in the
> right place before starting the build. If a second unzip step is too
> much for people, you could produce a source tarball for the Linux
> distros and a source tarball with all the binaries for Windows folks.
> Personally I think Windows users probably don't want the source, they
> would just want the compiled binaries.

You said it brother, that is pretty much what I was thinking of. :)

Thanks for your feedback pabs!

a.

-- 
Les plus beaux chants sont les chants de revendications
Le vers doit faire l'amour dans la tête des populations.
À l'école de la poésie, on n'apprend pas: on se bat!
                        - Léo Ferré, "Préface"

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

From: Pavel Kalian <pavel@kalian.cz>

To: Antoine Beaupré <anarcat@debian.org>, Paul Wise <pabs@debian.org>

Cc: 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sat, 21 Mar 2015 20:56:09 -0600

On 03/21/2015 07:18 PM, Antoine Beaupré wrote:
>>> Maybe we can have the two packages diverge (between ubuntu and Debian)
>>> at that level. Eventually, those differences would go away as 3.0 gets
>>> propagated everywhere...
>> Maybe with some macros and ifdefs you could default to wx 3.0 but allow
>> compiling with wx 2.8?
> >From what I understand, it can easily be built against 3.0 already. It
> may even autodetect whatever is there already.
While it can be built, it is pretty sure there are issues in how it
works with wx3 on Linux, it received very little testing upstream and
certainly won't get any but totally trivial and safe wx3 related fixes
in the 4.0 series.
Master leading to 4.2 is a different thing, but currently alpha quality
due to Android support landing.
Until Precise reaches EOL it's support will get precedence over Debian
as for upstream it represents more users with less skill, equaling to
more support "costs" if it stops to be totally straightforward.
>>> I am not sure. Maybe other DDs (in CC) can provide feedback here, but I
>>> would recommend providing a smaller tarball with only the OpenCPN source
>>> code. First it takes up less space on all the mirrors, and second it
>>> will make the FTP master's job easier.
>>>
>>> But my gut feeling is that binaries without source *will* be a problem,
>>> even if the software is free (like say wxWidgets).
>> Yes, that will be a problem. I would suggest doing this:
>>
>> Strip all the binaries and embedded code/data copies from your VCS
>> repository (git/svn/cvs/etc).
>>
>> Automate the source tarball build process with the `make distcheck`
>> target of autotools/cmake etc and just create a source tarball
>> (opencpn-1.0.tar.xz) with no binaries or embedded code/data copies.
>>
>> Automate the Windows build process and have it download the requisite
>> binaries at build time. Or if you prefer a Windows build without network
>> build access, create a script to download the Windows binaries and put
>> those in an opencpn-win32-dev.zip file that people can just unzip in the
>> right place before starting the build. If a second unzip step is too
>> much for people, you could produce a source tarball for the Linux
>> distros and a source tarball with all the binaries for Windows folks.
>> Personally I think Windows users probably don't want the source, they
>> would just want the compiled binaries.
> You said it brother, that is pretty much what I was thinking of. :)
>
> Thanks for your feedback pabs!
>
> a.
>
I would also love to live in a Debian/GNU centric world where Windows
users don't think they can build packages from source without reading
C++ for Dummies and OS X users that they use the only platform on
Earth... Unfortunately I don't ;)

Anyway, I have modified the Launchpad packaging scripts to strip
everything not needed for the Linux build while creating the source
tarball, how can it be submitted for review? Or should I submit a patch
for get-orig-source? Where and how
(http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/
seems a bit out of date)?

I suppose the data packages opencpn-doc, opencpn-gshhs and
opencpn-tcdata should be usable in the same form they already have on
Launchpad.

Thanks

Pavel

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

From: Antoine Beaupré <anarcat@debian.org>

To: Pavel Kalian <pavel@kalian.cz>, Paul Wise <pabs@debian.org>

Cc: 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sat, 21 Mar 2015 23:14:40 -0400

On 2015-03-21 22:56:09, Pavel Kalian wrote:
> On 03/21/2015 07:18 PM, Antoine Beaupré wrote:

[...]

> While it can be built, it is pretty sure there are issues in how it
> works with wx3 on Linux, it received very little testing upstream and
> certainly won't get any but totally trivial and safe wx3 related fixes
> in the 4.0 series.
> Master leading to 4.2 is a different thing, but currently alpha quality
> due to Android support landing.
> Until Precise reaches EOL it's support will get precedence over Debian
> as for upstream it represents more users with less skill, equaling to
> more support "costs" if it stops to be totally straightforward.

I understand. But my point is more that the Debian package can be made
to build against wx3 without forcing the Ubuntu side to do the same. We
could upload first to experimental for example and test out the
results.

If Ubuntu stability is important, maybe we should just diverge the
packages from the PPA from the packages uploaded into debian
directly. Eventually they will merge as the Debian packages trickle down
into the next Ubuntu releases...


[...]

> I would also love to live in a Debian/GNU centric world where Windows
> users don't think they can build packages from source without reading
> C++ for Dummies and OS X users that they use the only platform on
> Earth... Unfortunately I don't ;)

I am not sure that's what pabs was suggesting. :)

All that we're saying here is that there could be a base tarball with
just the OpenCPN source code (and I also believe the VCS repos should
hold only that) and a separate tarball with dependent libraries
builtin. At the VCS level, this could (for example) be accomplished
through git submodules.

However...

> Anyway, I have modified the Launchpad packaging scripts to strip
> everything not needed for the Linux build while creating the source
> tarball,

... while not the ideal solution in my mind, that's fine too! :)

> how can it be submitted for review?

Well, how do you manage the source now? Should we collaborate somewhere
or would you prefer the source for the Debian-specific packages to be
managed separately?

I often use "collab-maint" for such collaboration, but OpenCPN is a bit
special as it falls under the lead of the GIS team (in CC), and
therefore has its own set of tools. More information:

https://wiki.debian.org/CollaborativeMaintenance
https://wiki.debian.org/DebianGis

> Or should I submit a patch for get-orig-source?

I think that would be the most standard solution.

> Where and how
> (http://anonscm.debian.org/viewvc/pkg-grass/packages/opencpn/trunk/
> seems a bit out of date)?

I think that SVN repository was a different packaging effort than yours
(unless you started from there!) and should probably be disregarded at
this point, as it is outdated.

Furthermore, it seems the GIS team is switching to git:

https://wiki.debian.org/DebianGis/Svn2Git

So the proper place for the repository should probably be a git repo in
the GIS team. But I am not sure how to grant you access to that on
Alioth, maybe the GIS people can tell us here?

> I suppose the data packages opencpn-doc, opencpn-gshhs and
> opencpn-tcdata should be usable in the same form they already have on
> Launchpad.

I haven't reviewed those so I can't say, but I assume that's correct.

I will probably do a final review before sponsoring the upload
anyways. So far I am trusting you things were magically fixed, but
unfortunately I *will* need to do some more audit work before the upload
just to avoid pissing off the FTP-masters needlessly (the poor souls ;).

Thank you for your patience!

A.

-- 
Un éducateur dans l'âme ne prend rien au sérieux que par rapport
à ses disciples -- soi-même non excepté.
                        - Nietzsche, "Par delà le bien et le mal"

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

From: Paul Wise <pabs@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: Pavel Kalian <pavel@kalian.cz>, 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sun, 22 Mar 2015 12:57:15 +0800

[Message part 1 (text/plain, inline)]

On Sat, 2015-03-21 at 21:18 -0400, Antoine Beaupré wrote:

> TLDR; 2.8 was deliberately removed from jessie and is being kept from
> entering back because it is unmaintained upstream. I guess the remaining
> question is why it's even still in sid. :)

<pabs> olly: how come wxwidgets2.8 is still in unstable?
<olly> pabs: a few things there still depend on it, though it's really
time they moved on or moved out

> From what I understand, it can easily be built against 3.0 already. It
> may even autodetect whatever is there already.

Auto-detect would be ideal for people doing back-porting.

> You said it brother, that is pretty much what I was thinking of. :)

Great :)

> Thanks for your feedback pabs!

No probs!

Thanks for OpenCPN.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[signature.asc (application/pgp-signature, inline)]

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

From: Antoine Beaupré <anarcat@debian.org>

To: Pavel Kalian <pavel@kalian.cz>, Paul Wise <pabs@debian.org>

Cc: 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Fri, 22 Apr 2016 15:09:09 -0400

Hi Pavel,

Is there any progress on the OpenCPN packaging?

It would be great to see this in stretch!

From what I remember, the next step here is to publish your source tree
somewhere we can review, or just reuse the Ubuntu PPA.

How does that sound?

a.

-- 
Lorsque l'on range des objets dans des tiroirs, et que l'on a plus
d'objets que de tiroirs, alors un tiroir au moins contient deux
objets.
                        - Lejeune-Dirichlet, Peter Gustav

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

From: Pavel Kalian <pavel@kalian.cz>

To: Antoine Beaupré <anarcat@debian.org>

Cc: Paul Wise <pabs@debian.org>, 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Fri, 22 Apr 2016 16:20:57 -0300

[Message part 1 (text/plain, inline)]

Antoine…

Unfortunately I still did not receive any useful feedback from anybody, neither on Debian GIS mailing list, or any information on where I should submit something for review.

If you know what to look at, you may have a look at the launchpad sources at opencpn_4.2.0.orig.tar.xz <https://launchpad.net/~nohal/+archive/ubuntu/opencpn/+files/opencpn_4.2.0.orig.tar.xz> and tell me what they miss to be usable on debian (yes, the stuff present in the upstream git tree and not needed to build on linux is stripped from them)

Pavel
 
> On Apr 22, 2016, at 16:09, Antoine Beaupré <anarcat@debian.org> wrote:
> 
> Hi Pavel,
> 
> Is there any progress on the OpenCPN packaging?
> 
> It would be great to see this in stretch!
> 
>> From what I remember, the next step here is to publish your source tree
> somewhere we can review, or just reuse the Ubuntu PPA.
> 
> How does that sound?
> 
> a.
> 
> -- 
> Lorsque l'on range des objets dans des tiroirs, et que l'on a plus
> d'objets que de tiroirs, alors un tiroir au moins contient deux
> objets.
>                        - Lejeune-Dirichlet, Peter Gustav
> 

[Message part 2 (text/html, inline)]

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

From: Paul Wise <pabs@debian.org>

To: Pavel Kalian <pavel@kalian.cz>, Antoine Beaupré <anarcat@debian.org>

Cc: 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sat, 23 Apr 2016 11:34:46 +0800

[Message part 1 (text/plain, inline)]

On Fri, 2016-04-22 at 16:20 -0300, Pavel Kalian wrote:

> Unfortunately I still did not receive any useful feedback from
> anybody, neither on Debian GIS mailing list, or any information on
> where I should submit something for review.

Generally it works like this:

https://mentors.debian.net/intro-maintainers

Here is a review of this package:

https://launchpad.net/~nohal/+archive/ubuntu/opencpn/+files/opencpn_4.2.0-0~xenial1.dsc

Based on my review, not much has been fixed since I last reviewed it.

In my opinion these issues block the upload of this package:

Others may accept the package despite these issues but I wouldn't.

All the embedded code copies (wxSVG etc) need to be removed from the
upstream VCS repo and tarballs and packaged separately (some are now).
For folks on other platforms they could provide a dependencies tarball.

https://wiki.debian.org/EmbeddedCodeCopies

I encourage de-forking the modified embedded code copies (zygrib etc).

I encourage de-duplicating the duplicated embedded code copies (wxJSON etc).

I encourage removing the non-free embedded code copies (unrar) and
replacing them with dependencies on free equivalents (unar).

There are some generated files in the source package (see the
licensecheck output below), these should be removed from the upstream
VCS repo and tarballs and created at build time by the upstream build
system instead.

Some of the generated PNG images have got out of sync with their SVG
source, upstream needs to investigate this.

Some of the generated PNG images (pkg_background.jpg for eg) look like
they were generated from proprietary maps.

Some of the generated files (MathJax.js and *.min.*) do not have their
corresponding source available in the package. This may be either a GPL
violation or a DFSG violation depending on the license of those files.

Helvetica.txf seems to have been generated from a proprietary font.

There are some Depends/Recommends that need to be packaged and uploaded
before opencpn can be uploaded.

The debian/copyright file is not accurate, it needs to document the
copyright and licenses of all the files in the source package.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
http://people.skolelinux.org/pere/blog/Creating__updating_and_checking_debian_copyright_semi_automatically.html

In my opinion these issues would be nice to fix:

Please pass Debian's guide for upstreams along to the OpenCPN devs: 

https://wiki.debian.org/UpstreamGuide

data/license.txt is a copy of the GPL, there is no need to install that
in the package via debian/docs since it is in the common licenses dir.

/usr/share/common-licenses/

The new location for DEP-5 is on the Debian website:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

I suggest upgrading to debhelper compat 10 and using dh instead of
CDBS, but those are my personal preferences.

I suggest wrapping and sorting the debian/ dir using this command:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages --trailing-comma --verbose

Is there any reason not to uncomment the OpenGL ES dependencies?

#For the ARM build, perhaps add: , libdri2-dev [armhf],libgles1-mesa-dev [armhf]

OpenGL ES is available on all Debian packages of Mesa so you don't need
to restrict it to armhf though.

The commented out Vcs-* URLs don't exist, I would remove them.

The URL in the Homepage field redirects to here:

http://opencpn.org/ocpn/

The package description doesn't need to mention the license because
that is in debian/copyright. It doesn't need to mention that opencpn is
free software because it would be in Debian main if accepted.

You might want to update the package to the latest Standards-Version:

http://www.debian.org/doc/debian-policy/upgrading-checklist

How are you creating/editing debian/changelog? The normal method (dch)
inserts a blank line between the entries.

Some of the SVG files in the plugin dirs seem to be duplicated in the
src/ and data/ subdirs.

If possible I would recommend the screenshots be generated at build
time so that they represent the current platform being built for and
also so they don't get outdated as UI elements change.

data/copyright and data/changelog.Debian.gz look like an aborted
attempt at Debian packaging and should be removed.

Please add a debian/watch file:

https://wiki.debian.org/debian/watch

Please add some upstream metadata:

https://wiki.debian.org/UpstreamMetadata

Please consider fuzz testing any installed programs that could parse
untrusted input using zzuf and afl.

I would suggest upstream remove uncontrolled advertising from their
download page, especially if it is hijacking downloads.

Automated checks:

build

lots of compiler warnings
lots of dpkg-shlibdeps warnings

lintian

P: opencpn source: duplicate-in-relation-field in source build-depends: libgtk2.0-dev, libgtk2.0-dev
P: opencpn source: insane-line-length-in-source-file plugins/chartdldr_pi/data/doc/MathJax.js line length is 32123 characters (>512)
P: opencpn source: source-contains-prebuilt-javascript-object plugins/chartdldr_pi/data/doc/MathJax.js line length is 32123 characters (>512)
E: opencpn source: source-is-missing plugins/chartdldr_pi/data/doc/MathJax.js line length is 32123 characters (>512)
P: opencpn source: source-contains-prebuilt-javascript-object plugins/chartdldr_pi/data/doc/highlight.min.js
E: opencpn source: source-is-missing plugins/chartdldr_pi/data/doc/highlight.min.js
P: opencpn source: package-uses-old-debhelper-compat-version 8
P: opencpn source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5
W: opencpn source: dep5-copyright-license-name-not-unique (paragraph at line 24)
W: opencpn source: ancient-standards-version 3.9.3 (current is 3.9.7)
I: opencpn source: debian-watch-file-is-missing
<more>

check-all-the-things

# Checks style, feel free to ignore
$ find -type f \( -iname '*.sh' -o -iname '*.bash' \) -exec bashate --ignore E002,E003 {} +
<lots>

# Check with upstream where the Inkscape SVG source files are.
$ find -type f \( -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg' -o -iname '*.jpeg' \) -exec grep -iF inkscape {} +
Binary file ./plugins/wmm_pi/src/wmm_pi.png matches
Binary file ./plugins/wmm_pi/src/wmm.png matches
Binary file ./plugins/chartdldr_pi/data/open182.png matches
Binary file ./plugins/chartdldr_pi/data/folder215.png matches
Binary file ./plugins/chartdldr_pi/src/chartdldr.png matches
Binary file ./plugins/chartdldr_pi/src/chartdldr_pi.png matches
Binary file ./data/opencpn.png matches
Binary file ./src/bitmaps/opencpn.png matches
Binary file ./src/bitmaps/other_svg_src/opencpn_mobile0.png matches

$ find -type f -iname '*.sh' -exec checkbashisms {} +
could not find any possible bashisms in bash script ./plugins/grib_pi/src/icons.sh
could not find any possible bashisms in bash script ./plugins/wmm_pi/src/icons.sh
could not find any possible bashisms in bash script ./plugins/dashboard_pi/src/icons.sh
could not find any possible bashisms in bash script ./plugins/chartdldr_pi/src/icons.sh
could not find any possible bashisms in bash script ./src/bitmaps/28x28_svg_src/create_all_28x28.sh
could not find any possible bashisms in bash script ./src/bitmaps/32x32_svg_src/ribbon/create_all_32x32.sh
could not find any possible bashisms in bash script ./src/bitmaps/32x32_svg_src/cursor/create_all_32x32.sh
could not find any possible bashisms in bash script ./src/bitmaps/16x16_svg_src/create_all_16x16.sh
could not find any possible bashisms in bash script ./src/bitmaps/13xX_svg_src/create_all_13xX.sh
could not find any possible bashisms in bash script ./src/bitmaps/other_svg_src/create_ship.sh
could not find any possible bashisms in bash script ./src/bitmaps/other_svg_src/create_opencpn_main_icon.sh

$ cme check dpkg
...
Warning in 'control source Standards-Version' value '3.9.3': Current standards version is 3.9.8
Warning in 'control binary:opencpn Depends:3' value 'opencpn-tcdata': package opencpn-tcdata is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Depends:4' value 'opencpn-gshhs-low': package opencpn-gshhs-low is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Recommends:2' value 'opencpn-doc': package opencpn-doc is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Recommends:3' value 'opencpn-gshhs-crude': package opencpn-gshhs-crude is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Recommends:4' value 'opencpn-gshhs-intermediate': package opencpn-gshhs-intermediate is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Recommends:5' value 'opencpn-gshhs-high': package opencpn-gshhs-high is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Recommends:6' value 'opencpn-gshhs-full': package opencpn-gshhs-full is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Conflicts:0' value 'opencpn-plugin-wmm': package opencpn-plugin-wmm is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Conflicts:1' value 'opencpn-plugin-chartdldr': package opencpn-plugin-chartdldr is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Replaces:0' value 'opencpn-plugin-wmm': package opencpn-plugin-wmm is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Replaces:1' value 'opencpn-plugin-chartdldr': package opencpn-plugin-chartdldr is unknown. Check for typos if not a virtual package.
Warning in 'control binary:opencpn Description' value 'OpenCPN is a free software (GPLv2) project to create a concise chartplotter and navigation software for use as an underway or planning tool.  OpenCPN is developed by a team of active sailors using real world conditions for program testing and refinement.': Line too long in description
Warning in 'copyright Format' value 'http://dep.debian.net/deps/dep5': Format does not match the recommended URL for DEP-5
Warning in 'control source Build-Depends': Duplicated value: 11:"libgtk2.0-dev"

$ codespell --quiet-level=3
<lots>

$ cppcheck -j1 --quiet -f .
[plugins/chartdldr_pi/src/unrar/extract.cpp:36]: (error) Uninitialized struct member: FD.Size
[plugins/chartdldr_pi/src/unrar/recvol5.cpp:342]: (error) Memory leak: Data
<more>

$ debmake -k
<lots>

$ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;
./data/opencpn.desktop: hint: value "Education;Science;Geography;" for key "Categories" in group "Desktop Entry" contains more than one main category; application might appear more than once in the application menu

$ find \( -name .git -o -name .svn -o -name .bzr -o -name CVS -o -name .hg -o -name _darcs -o -name _FOSSIL_ -o -name .sgdrawer \) -prune -o -empty -print
./src/glu/libutil/.dirstamp

$ fdupes -q -r . | grep -vE '/(\.(git|svn|bzr|hg|sgdrawer)|_(darcs|FOSSIL_)|CVS)(/|$)' | cat -s
<lots>

$ grep -Er '/(home|srv|opt)(\W|$)' .
<lots>

$ flawfinder -Q -c .
<lots>

$ find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec POFileChecker {} +
<lots>

$ find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec POFileSpell {} +
<lots>

# check if these can be switched to https://
$ grep -rF http: .
<lots>

$ find -type f \( -iname '*.po' -o -iname '*.pot' -o -iname '*.mo' -o -iname '*.gmo' \) -exec i18nspector {} +
<lots>

$ find -type f \( -iname '*.c' -o -iname '*.cc' -o -iname '*.cxx' -o -iname '*.cpp' -o -iname '*.h' -o -iname '*.hh' -o -iname '*.hxx' -o -iname '*.hpp' \) -exec include-what-you-use {} \;
<lots>

$ find -type d \( -iname .git -o -iname .svn -o -iname .bzr -o -iname CVS -o -iname .hg -o -iname _darcs -o -iname _FOSSIL_ -o -iname .sgdrawer \) -prune -o -type f ! \( -iname '*.blend' -o -iname '*.icns' -o -iname '*.bmp' -o -iname '*.ico' -o -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.tga' -o -iname '*.xcf' -o -iname '*.tif' -o -iname '*.tiff' -o -iname '*.mo' -o -iname '*.gmo' -o -iname '*.gz' -o -iname '*.bz2' -o -iname '*.xz' -o -iname '*.lz' -o -iname '*.zip' -o -iname '*.tar' -o -iname '*.deb' -o -iname '*.pdf' -o -iname '*.odt' -o -iname '*.docx' -o -iname '*.doc' -o -iname '*.chm' -o -iname '*.torrent' -o -iname '*.pyc' -o -iname '*.pyo' -o -iname '*.o' -o -iname '*.so' -o -iname '*.so.*' -o -iname '*.debug' -o -iname '*.wav' -o -iname '*.ogg' -o -iname '*.oga' -o -iname '*.ogv' -o -iname '*.mid' -o -iname '*.mp3' -o -iname '*.flac' -o -iname '*.ttf' -o -iname '*.otf' -o -iname '*.fon' -o -iname '*.pgp' -o -iname '*.gpg' -o -iname '*.dat' \) -exec isutf8 {} +
./plugins/dashboard_pi/src/wind.cpp: line 190, char 1, byte offset 29: invalid UTF-8 code
./plugins/chartdldr_pi/src/unrar/rs16.cpp: line 147, char 1, byte offset 15: invalid UTF-8 code

$ license-reconcile
<lots>

$ grep -rE -- '-m64|-m32' .
./plugins/chartdldr_pi/src/unrar/makefile:#CXXFLAGS=-O3 -mcpu=v9 -mtune=ultrasparc -m32

$ find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt --check --check-compatibility --check-accelerators --output-file=/dev/null {} \;
<lots>

$ find -type f -iname '*.py' -exec pep8 --ignore W191 {} +
./src/glshim/spec/gen.py:15:1: E302 expected 2 blank lines, found 1
./src/glshim/spec/gen.py:43:1: E302 expected 2 blank lines, found 1
./src/glshim/spec/gen.py:56:1: E302 expected 2 blank lines, found 1
./src/glshim/spec/gen.py:66:1: E302 expected 2 blank lines, found 1
./src/glshim/spec/gen.py:73:1: E302 expected 2 blank lines, found 1
./src/glshim/spec/gen.py:116:16: E713 test for membership should be 'not in'
./src/glshim/spec/gen.py:135:80: E501 line too long (81 > 79 characters)
./src/glshim/spec/gen.py:140:80: E501 line too long (81 > 79 characters)
./src/glshim/spec/xml/toyml.py:53:20: E713 test for membership should be 'not in'
./src/glshim/spec/xml/toyml.py:53:80: E501 line too long (80 > 79 characters)
./src/glshim/spec/xml/toyml.py:110:1: W293 blank line contains whitespace

$ perlcritic -1 . 2>&1 | grep -vF 'No perl files were found.'
<lots>

$ find -type f -iname '*.py' -exec pyflakes3 {} +
./src/glshim/spec/gen.py:158:13: invalid syntax
    print gen(files, args.template, args.name,
            ^
./src/glshim/spec/xml/toyml.py:99:38: invalid syntax
        print 'unrecognized root tag:', xml.tag

$ find -type f -iname '*.py' -exec pylint --msg-template='{path}:{line}:{column}: [{category}:{symbol}] {obj}: {msg}' --reports=n {} +
<lots>

$ find -type f -iname '*.py' -exec pylint3 --msg-template='{path}:{line}:{column}: [{category}:{symbol}] {obj}: {msg}' --reports=n {} +
No config file found, using default configuration
************* Module gen
src/glshim/spec/gen.py:158:0: [error:syntax-error] : invalid syntax
************* Module toyml
src/glshim/spec/xml/toyml.py:99:0: [error:syntax-error] : Missing parentheses in call to 'print'

# Users of binary packages do not need install instructions.
$ find -type f -iname '*README*' -a ! \( -iname README.md -o -iname README.rst -o -iname README.install \) -exec grep --ignore-case --fixed-strings --with-filename install {} +
./data/sounds/README.bells:Installation
./data/sounds/README.bells:The files 1bells, 2bells..., 8bells should be placed in the "sounds" directory under the main OpenCPN installation directory. The sounds are enabled by selecting the appropriate option in the Toolbox->Etc dialog.
./data/doc/readme:To link to "Installing Charts", the link that users see and click on _must_ be "Installing Charts", not even including a final "." !!

$ find -type f \( -iname '*.sh' -o -iname '*.bash' -o -iname '*.zsh' \) -exec shellcheck {} +
<lots>

$ find -type d \( -iname .bzr -o -iname .git -o -iname .hg -o -iname .svn -o -iname CVS -o -iname RCS -o -iname SCCS -o -iname _MTN -o -iname _darcs -o -iname .pc -o -iname .cabal-sandbox -o -iname .cdv -o -iname .metadata -o -iname CMakeFiles -o -iname _build -o -iname _sgbak -o -iname autom4te.cache -o -iname blib -o -iname cover_db -o -iname node_modules -o -iname '~.dep' -o -iname '~.dot' -o -iname '~.nib' -o -iname '~.plst' \) -prune -o -type f ! \( -iname '*.bak' -o -iname '*.swp' -o -iname '#.*' -o -iname '#*#' -o -iname 'core.*' -o -iname '*~' -o -iname '*.gif' -o -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.png' -o -iname '*.min.js' -o -iname '*.js.map' -o -iname '*.js.min' -o -iname '*.min.css' -o -iname '*.css.map' -o -iname '*.css.min' \) -exec spellintian --picky {} +
<lots>

$ suspicious-source
./plugins/wmm_pi/unused-data/EGM9615.BIN
./data/changelog.Debian.gz
./data/s57data/Helvetica.txf
./data/s57data/S52RAZDS.RLE

# Prevents reproducible builds: http://reproducible-builds.org/
$ grep -rE ' __DATE__|__TIME__' .
./src/glshim/src/glx/glx.c:    printf("libGL: built on %s %s\n", __DATE__, __TIME__);

# Potential tmpfile vulnerabilities
$ grep -r '/tmp/' .
./plugins/grib_pi/src/email.cpp:        filename.Printf(wxT("/tmp/msg-%ld-%ld-%ld.txt"), (long) getpid(), wxGetLocalTime(),
./src/chart1.cpp:    f = fopen("/var/tmp/serial", "r");
./src/chart1.cpp:    f = fopen("/var/tmp/usbserial", "r");
./src/mygdal/cpl_path.cpp: * CPLProjectRelativeFilename("abc/def","tmp/abc.gif") == "abc/def/tmp/abc.gif"
./src/mygdal/cpl_path.cpp: * CPLProjectRelativeFilename("abc/def","/tmp/abc.gif") == "/tmp/abc.gif"
./src/ocpnhelper.c:	                 if((ouF = open("/var/tmp/usbserial", O_WRONLY | O_CREAT | O_TRUNC, 0777)) != -1)
./src/ocpnhelper.c:	                 if((ouF = open("/var/tmp/serial", O_WRONLY | O_CREAT | O_TRUNC, 0777)) != -1)
./src/ocpnhelper.c:                unlink("/var/tmp/usbserial");
./src/ocpnhelper.c:                unlink("/var/tmp/serial");
./src/glshim/src/gl/pixel.c:    snprintf(filename, 64, "/tmp/tex.%d.ppm", name);

$ grep -riE 'fixme|todo|hack|xxx|broken' .
<lots>

$ find .. -maxdepth 1 -type f -iwholename '../*.build' -exec blhc --all {} +
CXXFLAGS missing (-fPIE): <lots>
LDFLAGS missing (-Wl,-z,relro -Wl,-z,now): ...

$ grep -H -i warn ../*.build
<lots>

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[signature.asc (application/pgp-signature, inline)]

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

From: Paul Wise <pabs@debian.org>

To: Pavel Kalian <pavel@kalian.cz>, Antoine Beaupré <anarcat@debian.org>

Cc: 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sat, 23 Apr 2016 11:37:47 +0800

[Message part 1 (text/plain, inline)]

On Fri, 2016-04-22 at 16:20 -0300, Pavel Kalian wrote:

> (yes, the stuff present in the upstream git tree and not needed to
> build on linux is stripped from them)

I forgot to mention that you should use Files-Excluded in
debian/copyright so that others can reproduce your removals:

https://wiki.debian.org/UscanEnhancements
https://wiki.debian.org/debian/watch

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[signature.asc (application/pgp-signature, inline)]

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

From: Pavel Kalian <pavel@kalian.cz>

To: Paul Wise <pabs@debian.org>

Cc: Antoine Beaupré <anarcat@debian.org>, 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Sun, 24 Apr 2016 09:19:56 -0300

Paul…
Many thanks for the review.

> On Apr 23, 2016, at 00:34, Paul Wise <pabs@debian.org> wrote:
> 
> On Fri, 2016-04-22 at 16:20 -0300, Pavel Kalian wrote:
> 
>> Unfortunately I still did not receive any useful feedback from
>> anybody, neither on Debian GIS mailing list, or any information on
>> where I should submit something for review.
> 
> Generally it works like this:
> 
> https://mentors.debian.net/intro-maintainers
> 
> Here is a review of this package:
> 
> https://launchpad.net/~nohal/+archive/ubuntu/opencpn/+files/opencpn_4.2.0-0~xenial1.dsc
> 
> Based on my review, not much has been fixed since I last reviewed it.
> 
> In my opinion these issues block the upload of this package:
> 
> Others may accept the package despite these issues but I wouldn't.
> 
> All the embedded code copies (wxSVG etc) need to be removed from the
> upstream VCS repo and tarballs and packaged separately (some are now).
> For folks on other platforms they could provide a dependencies tarball.
> 
> https://wiki.debian.org/EmbeddedCodeCopies
The linked document says “Debian packages *should* not use convenience copies”, is it now changed to a hard requirement? It would IMO be unfortunate for the upstream to have to make the build from Git more complicated and per se broken for 99% of the people because of the packaging requirements of one single flavor of one single platform, especially as the files possibly offending Debian can be removed during the creation of the tarball. The embedded code also receives fixes for problems that affect us, which is just natural to handle in a VCS, not by making people watch for updates to some tarball (Which they fail to do as we know by experience). We do not include copies of libraries that do not need patching or where upstream exists and accepts patches.
Also, I wonder what sense does it make to create packages nobody else uses? (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813151)

> 
> I encourage de-forking the modified embedded code copies (zygrib etc).
While OpenCPN’s grib implementation originally came from zygrib many years ago, they are completely different now, how do you imagine the de-forking to be done? Same with GDAL etc.
Is this a hard requirement? If so, I’m afraid the Debian inclusion is out of question as zygrib internally is a Qt application, not a library, while OpenCPN is a wxWidgets application.

> 
> I encourage de-duplicating the duplicated embedded code copies (wxJSON etc).

It is upstream policy that the plugins have to be buildable completely independently of the core source tree.

> 
> I encourage removing the non-free embedded code copies (unrar) and
> replacing them with dependencies on free equivalents (unar).

No problem, done and ready to be pushed upstream.

> 
> There are some generated files in the source package (see the
> licensecheck output below), these should be removed from the upstream
> VCS repo and tarballs and created at build time by the upstream build
> system instead.
> 
> Some of the generated PNG images have got out of sync with their SVG
> source, upstream needs to investigate this.
There is no problem as far as I can see, the SVGs being “out of sync” are not meant to be “in sync” but are “original artwork templates".

> 
> Some of the generated PNG images (pkg_background.jpg for eg) look like
> they were generated from proprietary maps.

Do you say that taking a screenshot of a public domain chart (NOAA copyright states “No copyright is claimed by the United States Government under Title 17 U.S.C.") produces an image incompatible with GPL? They of course can be removed, I’m just wondering if this situation is really considered problematic.

> 
> Some of the generated files (MathJax.js and *.min.*) do not have their
> corresponding source available in the package. This may be either a GPL
> violation or a DFSG violation depending on the license of those files.
Resolved, ready to be ushed upstream.

> 
> Helvetica.txf seems to have been generated from a proprietary font.
I’m confused, this file is already distributed by Debian in several packages. Is it now a hard requirement to replace it with another font in new packages?

> 
> There are some Depends/Recommends that need to be packaged and uploaded
> before opencpn can be uploaded.

You mean the opencpn-* data packages? Yes, they will be submitted once it will look like there is a chance the packaging effort is going to be succesful. Should be much easier than the code.

> 
> The debian/copyright file is not accurate, it needs to document the
> copyright and licenses of all the files in the source package.
> 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> http://people.skolelinux.org/pere/blog/Creating__updating_and_checking_debian_copyright_semi_automatically.html
> 
> In my opinion these issues would be nice to fix:
> 
> Please pass Debian's guide for upstreams along to the OpenCPN devs: 
> 
> https://wiki.debian.org/UpstreamGuide
> 
> data/license.txt is a copy of the GPL, there is no need to install that
> in the package via debian/docs since it is in the common licenses dir.
> 
> /usr/share/common-licenses/
> 
> The new location for DEP-5 is on the Debian website:
> 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> 
> I suggest upgrading to debhelper compat 10 and using dh instead of
> CDBS, but those are my personal preferences.
> 
> I suggest wrapping and sorting the debian/ dir using this command:
> 
> wrap-and-sort --short-indent --wrap-always --sort-binary-packages --trailing-comma --verbose
> 
> Is there any reason not to uncomment the OpenGL ES dependencies?
> 
> #For the ARM build, perhaps add: , libdri2-dev [armhf],libgles1-mesa-dev [armhf]
> 
> OpenGL ES is available on all Debian packages of Mesa so you don't need
> to restrict it to armhf though.
> 
> The commented out Vcs-* URLs don't exist, I would remove them.
> 
> The URL in the Homepage field redirects to here:
> 
> http://opencpn.org/ocpn/
> 
> The package description doesn't need to mention the license because
> that is in debian/copyright. It doesn't need to mention that opencpn is
> free software because it would be in Debian main if accepted.
> 
> You might want to update the package to the latest Standards-Version:
> 
> http://www.debian.org/doc/debian-policy/upgrading-checklist
> 
> How are you creating/editing debian/changelog? The normal method (dch)
> inserts a blank line between the entries.
> 
> Some of the SVG files in the plugin dirs seem to be duplicated in the
> src/ and data/ subdirs.
> 
> If possible I would recommend the screenshots be generated at build
> time so that they represent the current platform being built for and
> also so they don't get outdated as UI elements change.
> 
> data/copyright and data/changelog.Debian.gz look like an aborted
> attempt at Debian packaging and should be removed.
> 
> Please add a debian/watch file:
> 
> https://wiki.debian.org/debian/watch
> 
> Please add some upstream metadata:
> 
> https://wiki.debian.org/UpstreamMetadata
> 
> Please consider fuzz testing any installed programs that could parse
> untrusted input using zzuf and afl.
> 
> I would suggest upstream remove uncontrolled advertising from their
> download page, especially if it is hijacking downloads.

Does this have something to do with Debain packaging? Is it a hard requirement? Not saying upstream would not like to do the same, just curious.

> 
> Automated checks:
> 
> build
> 
> lots of compiler warnings
> lots of dpkg-shlibdeps warnings
> 
> lintian
> 
> P: opencpn source: duplicate-in-relation-field in source build-depends: libgtk2.0-dev, libgtk2.0-dev
> P: opencpn source: insane-line-length-in-source-file plugins/chartdldr_pi/data/doc/MathJax.js line length is 32123 characters (>512)
> P: opencpn source: source-contains-prebuilt-javascript-object plugins/chartdldr_pi/data/doc/MathJax.js line length is 32123 characters (>512)
> E: opencpn source: source-is-missing plugins/chartdldr_pi/data/doc/MathJax.js line length is 32123 characters (>512)
> P: opencpn source: source-contains-prebuilt-javascript-object plugins/chartdldr_pi/data/doc/highlight.min.js
> E: opencpn source: source-is-missing plugins/chartdldr_pi/data/doc/highlight.min.js
> P: opencpn source: package-uses-old-debhelper-compat-version 8
> P: opencpn source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5
> W: opencpn source: dep5-copyright-license-name-not-unique (paragraph at line 24)
> W: opencpn source: ancient-standards-version 3.9.3 (current is 3.9.7)
> I: opencpn source: debian-watch-file-is-missing
> <more>
> 
> check-all-the-things
> 
> # Checks style, feel free to ignore
> $ find -type f \( -iname '*.sh' -o -iname '*.bash' \) -exec bashate --ignore E002,E003 {} +
> <lots>
> 
> # Check with upstream where the Inkscape SVG source files are.
> $ find -type f \( -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg' -o -iname '*.jpeg' \) -exec grep -iF inkscape {} +
> Binary file ./plugins/wmm_pi/src/wmm_pi.png matches
> Binary file ./plugins/wmm_pi/src/wmm.png matches
> Binary file ./plugins/chartdldr_pi/data/open182.png matches
> Binary file ./plugins/chartdldr_pi/data/folder215.png matches
> Binary file ./plugins/chartdldr_pi/src/chartdldr.png matches
> Binary file ./plugins/chartdldr_pi/src/chartdldr_pi.png matches
> Binary file ./data/opencpn.png matches
> Binary file ./src/bitmaps/opencpn.png matches
> Binary file ./src/bitmaps/other_svg_src/opencpn_mobile0.png matches
> 
> $ find -type f -iname '*.sh' -exec checkbashisms {} +
> could not find any possible bashisms in bash script ./plugins/grib_pi/src/icons.sh
> could not find any possible bashisms in bash script ./plugins/wmm_pi/src/icons.sh
> could not find any possible bashisms in bash script ./plugins/dashboard_pi/src/icons.sh
> could not find any possible bashisms in bash script ./plugins/chartdldr_pi/src/icons.sh
> could not find any possible bashisms in bash script ./src/bitmaps/28x28_svg_src/create_all_28x28.sh
> could not find any possible bashisms in bash script ./src/bitmaps/32x32_svg_src/ribbon/create_all_32x32.sh
> could not find any possible bashisms in bash script ./src/bitmaps/32x32_svg_src/cursor/create_all_32x32.sh
> could not find any possible bashisms in bash script ./src/bitmaps/16x16_svg_src/create_all_16x16.sh
> could not find any possible bashisms in bash script ./src/bitmaps/13xX_svg_src/create_all_13xX.sh
> could not find any possible bashisms in bash script ./src/bitmaps/other_svg_src/create_ship.sh
> could not find any possible bashisms in bash script ./src/bitmaps/other_svg_src/create_opencpn_main_icon.sh
> 
> $ cme check dpkg
> ...
> Warning in 'control source Standards-Version' value '3.9.3': Current standards version is 3.9.8
> Warning in 'control binary:opencpn Depends:3' value 'opencpn-tcdata': package opencpn-tcdata is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Depends:4' value 'opencpn-gshhs-low': package opencpn-gshhs-low is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Recommends:2' value 'opencpn-doc': package opencpn-doc is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Recommends:3' value 'opencpn-gshhs-crude': package opencpn-gshhs-crude is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Recommends:4' value 'opencpn-gshhs-intermediate': package opencpn-gshhs-intermediate is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Recommends:5' value 'opencpn-gshhs-high': package opencpn-gshhs-high is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Recommends:6' value 'opencpn-gshhs-full': package opencpn-gshhs-full is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Conflicts:0' value 'opencpn-plugin-wmm': package opencpn-plugin-wmm is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Conflicts:1' value 'opencpn-plugin-chartdldr': package opencpn-plugin-chartdldr is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Replaces:0' value 'opencpn-plugin-wmm': package opencpn-plugin-wmm is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Replaces:1' value 'opencpn-plugin-chartdldr': package opencpn-plugin-chartdldr is unknown. Check for typos if not a virtual package.
> Warning in 'control binary:opencpn Description' value 'OpenCPN is a free software (GPLv2) project to create a concise chartplotter and navigation software for use as an underway or planning tool.  OpenCPN is developed by a team of active sailors using real world conditions for program testing and refinement.': Line too long in description
> Warning in 'copyright Format' value 'http://dep.debian.net/deps/dep5': Format does not match the recommended URL for DEP-5
> Warning in 'control source Build-Depends': Duplicated value: 11:"libgtk2.0-dev"
> 
> $ codespell --quiet-level=3
> <lots>
> 
> $ cppcheck -j1 --quiet -f .
> [plugins/chartdldr_pi/src/unrar/extract.cpp:36]: (error) Uninitialized struct member: FD.Size
> [plugins/chartdldr_pi/src/unrar/recvol5.cpp:342]: (error) Memory leak: Data
> <more>
> 
> $ debmake -k
> <lots>
> 
> $ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;
> ./data/opencpn.desktop: hint: value "Education;Science;Geography;" for key "Categories" in group "Desktop Entry" contains more than one main category; application might appear more than once in the application menu
> 
> $ find \( -name .git -o -name .svn -o -name .bzr -o -name CVS -o -name .hg -o -name _darcs -o -name _FOSSIL_ -o -name .sgdrawer \) -prune -o -empty -print
> ./src/glu/libutil/.dirstamp
> 
> $ fdupes -q -r . | grep -vE '/(\.(git|svn|bzr|hg|sgdrawer)|_(darcs|FOSSIL_)|CVS)(/|$)' | cat -s
> <lots>
> 
> $ grep -Er '/(home|srv|opt)(\W|$)' .
> <lots>
> 
> $ flawfinder -Q -c .
> <lots>
> 
> $ find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec POFileChecker {} +
> <lots>
> 
> $ find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec POFileSpell {} +
> <lots>
> 
> # check if these can be switched to https://
> $ grep -rF http: .
> <lots>
> 
> $ find -type f \( -iname '*.po' -o -iname '*.pot' -o -iname '*.mo' -o -iname '*.gmo' \) -exec i18nspector {} +
> <lots>
> 
> $ find -type f \( -iname '*.c' -o -iname '*.cc' -o -iname '*.cxx' -o -iname '*.cpp' -o -iname '*.h' -o -iname '*.hh' -o -iname '*.hxx' -o -iname '*.hpp' \) -exec include-what-you-use {} \;
> <lots>
> 
> $ find -type d \( -iname .git -o -iname .svn -o -iname .bzr -o -iname CVS -o -iname .hg -o -iname _darcs -o -iname _FOSSIL_ -o -iname .sgdrawer \) -prune -o -type f ! \( -iname '*.blend' -o -iname '*.icns' -o -iname '*.bmp' -o -iname '*.ico' -o -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.tga' -o -iname '*.xcf' -o -iname '*.tif' -o -iname '*.tiff' -o -iname '*.mo' -o -iname '*.gmo' -o -iname '*.gz' -o -iname '*.bz2' -o -iname '*.xz' -o -iname '*.lz' -o -iname '*.zip' -o -iname '*.tar' -o -iname '*.deb' -o -iname '*.pdf' -o -iname '*.odt' -o -iname '*.docx' -o -iname '*.doc' -o -iname '*.chm' -o -iname '*.torrent' -o -iname '*.pyc' -o -iname '*.pyo' -o -iname '*.o' -o -iname '*.so' -o -iname '*.so.*' -o -iname '*.debug' -o -iname '*.wav' -o -iname '*.ogg' -o -iname '*.oga' -o -iname '*.ogv' -o -iname '*.mid' -o -iname '*.mp3' -o -iname '*.flac' -o -iname '*.ttf' -o -iname '*.otf' -o -iname '*.fon' -o -iname '*.pgp' -o -iname '*.gpg' -o -iname '*.dat' \) -exec isutf8 {} +
> ./plugins/dashboard_pi/src/wind.cpp: line 190, char 1, byte offset 29: invalid UTF-8 code
> ./plugins/chartdldr_pi/src/unrar/rs16.cpp: line 147, char 1, byte offset 15: invalid UTF-8 code
> 
> $ license-reconcile
> <lots>
> 
> $ grep -rE -- '-m64|-m32' .
> ./plugins/chartdldr_pi/src/unrar/makefile:#CXXFLAGS=-O3 -mcpu=v9 -mtune=ultrasparc -m32
> 
> $ find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt --check --check-compatibility --check-accelerators --output-file=/dev/null {} \;
> <lots>
> 
> $ find -type f -iname '*.py' -exec pep8 --ignore W191 {} +
> ./src/glshim/spec/gen.py:15:1: E302 expected 2 blank lines, found 1
> ./src/glshim/spec/gen.py:43:1: E302 expected 2 blank lines, found 1
> ./src/glshim/spec/gen.py:56:1: E302 expected 2 blank lines, found 1
> ./src/glshim/spec/gen.py:66:1: E302 expected 2 blank lines, found 1
> ./src/glshim/spec/gen.py:73:1: E302 expected 2 blank lines, found 1
> ./src/glshim/spec/gen.py:116:16: E713 test for membership should be 'not in'
> ./src/glshim/spec/gen.py:135:80: E501 line too long (81 > 79 characters)
> ./src/glshim/spec/gen.py:140:80: E501 line too long (81 > 79 characters)
> ./src/glshim/spec/xml/toyml.py:53:20: E713 test for membership should be 'not in'
> ./src/glshim/spec/xml/toyml.py:53:80: E501 line too long (80 > 79 characters)
> ./src/glshim/spec/xml/toyml.py:110:1: W293 blank line contains whitespace
> 
> $ perlcritic -1 . 2>&1 | grep -vF 'No perl files were found.'
> <lots>
> 
> $ find -type f -iname '*.py' -exec pyflakes3 {} +
> ./src/glshim/spec/gen.py:158:13: invalid syntax
>     print gen(files, args.template, args.name,
>             ^
> ./src/glshim/spec/xml/toyml.py:99:38: invalid syntax
>         print 'unrecognized root tag:', xml.tag
> 
> $ find -type f -iname '*.py' -exec pylint --msg-template='{path}:{line}:{column}: [{category}:{symbol}] {obj}: {msg}' --reports=n {} +
> <lots>
> 
> $ find -type f -iname '*.py' -exec pylint3 --msg-template='{path}:{line}:{column}: [{category}:{symbol}] {obj}: {msg}' --reports=n {} +
> No config file found, using default configuration
> ************* Module gen
> src/glshim/spec/gen.py:158:0: [error:syntax-error] : invalid syntax
> ************* Module toyml
> src/glshim/spec/xml/toyml.py:99:0: [error:syntax-error] : Missing parentheses in call to 'print'
> 
> # Users of binary packages do not need install instructions.
> $ find -type f -iname '*README*' -a ! \( -iname README.md -o -iname README.rst -o -iname README.install \) -exec grep --ignore-case --fixed-strings --with-filename install {} +
> ./data/sounds/README.bells:Installation
> ./data/sounds/README.bells:The files 1bells, 2bells..., 8bells should be placed in the "sounds" directory under the main OpenCPN installation directory. The sounds are enabled by selecting the appropriate option in the Toolbox->Etc dialog.
> ./data/doc/readme:To link to "Installing Charts", the link that users see and click on _must_ be "Installing Charts", not even including a final "." !!
> 
> $ find -type f \( -iname '*.sh' -o -iname '*.bash' -o -iname '*.zsh' \) -exec shellcheck {} +
> <lots>
> 
> $ find -type d \( -iname .bzr -o -iname .git -o -iname .hg -o -iname .svn -o -iname CVS -o -iname RCS -o -iname SCCS -o -iname _MTN -o -iname _darcs -o -iname .pc -o -iname .cabal-sandbox -o -iname .cdv -o -iname .metadata -o -iname CMakeFiles -o -iname _build -o -iname _sgbak -o -iname autom4te.cache -o -iname blib -o -iname cover_db -o -iname node_modules -o -iname '~.dep' -o -iname '~.dot' -o -iname '~.nib' -o -iname '~.plst' \) -prune -o -type f ! \( -iname '*.bak' -o -iname '*.swp' -o -iname '#.*' -o -iname '#*#' -o -iname 'core.*' -o -iname '*~' -o -iname '*.gif' -o -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.png' -o -iname '*.min.js' -o -iname '*.js.map' -o -iname '*.js.min' -o -iname '*.min.css' -o -iname '*.css.map' -o -iname '*.css.min' \) -exec spellintian --picky {} +
> <lots>
> 
> $ suspicious-source
> ./plugins/wmm_pi/unused-data/EGM9615.BIN
> ./data/changelog.Debian.gz
> ./data/s57data/Helvetica.txf
> ./data/s57data/S52RAZDS.RLE
> 
> # Prevents reproducible builds: http://reproducible-builds.org/
> $ grep -rE ' __DATE__|__TIME__' .
> ./src/glshim/src/glx/glx.c:    printf("libGL: built on %s %s\n", __DATE__, __TIME__);
> 
> # Potential tmpfile vulnerabilities
> $ grep -r '/tmp/' .
> ./plugins/grib_pi/src/email.cpp:        filename.Printf(wxT("/tmp/msg-%ld-%ld-%ld.txt"), (long) getpid(), wxGetLocalTime(),
> ./src/chart1.cpp:    f = fopen("/var/tmp/serial", "r");
> ./src/chart1.cpp:    f = fopen("/var/tmp/usbserial", "r");
> ./src/mygdal/cpl_path.cpp: * CPLProjectRelativeFilename("abc/def","tmp/abc.gif") == "abc/def/tmp/abc.gif"
> ./src/mygdal/cpl_path.cpp: * CPLProjectRelativeFilename("abc/def","/tmp/abc.gif") == "/tmp/abc.gif"
> ./src/ocpnhelper.c:	                 if((ouF = open("/var/tmp/usbserial", O_WRONLY | O_CREAT | O_TRUNC, 0777)) != -1)
> ./src/ocpnhelper.c:	                 if((ouF = open("/var/tmp/serial", O_WRONLY | O_CREAT | O_TRUNC, 0777)) != -1)
> ./src/ocpnhelper.c:                unlink("/var/tmp/usbserial");
> ./src/ocpnhelper.c:                unlink("/var/tmp/serial");
> ./src/glshim/src/gl/pixel.c:    snprintf(filename, 64, "/tmp/tex.%d.ppm", name);
> 
> $ grep -riE 'fixme|todo|hack|xxx|broken' .
> <lots>
> 
> $ find .. -maxdepth 1 -type f -iwholename '../*.build' -exec blhc --all {} +
> CXXFLAGS missing (-fPIE): <lots>
> LDFLAGS missing (-Wl,-z,relro -Wl,-z,now): ...
> 
> $ grep -H -i warn ../*.build
> <lots>
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise
> 
> 

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

From: Paul Wise <pabs@debian.org>

To: Pavel Kalian <pavel@kalian.cz>

Cc: Antoine Beaupré <anarcat@debian.org>, 538067@bugs.debian.org, debian-gis@lists.debian.org, Hamish <hamish_b@yahoo.com>, Andreas Tille <tille@debian.org>

Subject: Re: status of the opencpn PPA for inclusion in Debian

Date: Mon, 25 Apr 2016 10:22:21 +0800

[Message part 1 (text/plain, inline)]

On Sun, 2016-04-24 at 09:19 -0300, Pavel Kalian wrote:

> The linked document says “Debian packages *should* not use
> convenience copies”, is it now changed to a hard requirement?

I personally would not sponsor packages where I knew there were
embedded code copies. Others may have less strict standards.

> It would IMO be unfortunate for the upstream to have to make the
> build from Git more complicated

It doesn't have to be more complicated at all, just add an optional
automated dependency download step to the build process. Debian can
then skip that step and everyone will be happy.

> per se broken for 99% of the people

99% of people are served by binary packages, source tarballs are
generally only for advanced users and redistributors.

> Also, I wonder what sense does it make to create packages nobody else
> uses? (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813151)

I expect someone needed it for something but then plans changed etc.

Should be relatively easy to reintroduce since packaging exists:

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

> While OpenCPN’s grib implementation originally came from zygrib many
> years ago, they are completely different now, how do you imagine the
> de-forking to be done? Same with GDAL etc.
> Is this a hard requirement? If so, I’m afraid the Debian inclusion is
> out of question as zygrib internally is a Qt application, not a
> library, while OpenCPN is a wxWidgets application.

I wasn't aware zygrib was a Qt application. In the ideal world there
would be a GRIB library that could be shared by all the applications
supporting the GRIB format, instead of everyone re-implementing this.
Based on Wikipedia there appear to be some possibilities for this:

https://en.wikipedia.org/wiki/GRIB

GDAL is already a library so in an ideal world the opencpn changes to
that could be merged into GDAL and opencpn could depend on that.

I hope the opencpn GDAL is based on something newer than 1.9.1 as there
was a security issue fixed by Fedora in that version.

https://lwn.net/Alerts/536077/

Obviously we don't live in an ideal world though :)

Where it isn't possible to de-fork code, the Debian security team
stores info about the providence of that code, so if an issue arises in
the original code, we know the fork needs to be fixed too.

> It is upstream policy that the plugins have to be buildable
> completely independently of the core source tree.

Could you explain the reasoning here?

> No problem, done and ready to be pushed upstream.

Thanks!

> There is no problem as far as I can see, the SVGs being “out of sync”
> are not meant to be “in sync” but are “original artwork templates".

I don't understand what you mean, could you explain?

> Do you say that taking a screenshot of a public domain chart (NOAA
> copyright states “No copyright is claimed by the United States
> Government under Title 17 U.S.C.") produces an image incompatible
> with GPL? They of course can be removed, I’m just wondering if this
> situation is really considered problematic.

I wasn't aware it was public domain. However, IIRC USA govt works are
only in the public domain within the USA and they still reserve
copyright outside the USA. That said, this is probably ignorable.

> Resolved, ready to be ushed upstream.

Thanks.

> I’m confused, this file is already distributed by Debian in several
> packages. Is it now a hard requirement to replace it with another
> font in new packages?

If it is actually from a proprietary font, then probably yes.
More likely is the situation is more complicated than that.

Do you know the origin of Helvetica.txf in opencpn?

BTW, what format is .txf?

> You mean the opencpn-* data packages?

Yes.

> Does this have something to do with Debain packaging? Is it a hard
> requirement? Not saying upstream would not like to do the same, just
> curious.

No, just something I saw on the upstream download that worried me a
lot, if advertisers are known to hijack downloads, that is scary.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[signature.asc (application/pgp-signature, inline)]

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

From: Andreas Tille <andreas@an3as.eu>

To: 538067@bugs.debian.org, Debian GIS Project <debian-gis@lists.debian.org>

Subject: Moved packaging of OpenCPN from SVN to Git

Date: Thu, 22 Feb 2018 19:30:42 +0100

Hi,

since I once touched OpenCPN as my first SoB project[1] I wanted to save
the work done at that time and moved the packaging from SVN to Git[2].  I
do not plan to do any further work on this package - may be somebody else
is motivated to keep on the work.

Kind regards

         Andreas.


[1] https://wiki.debian.org/DebianPureBlends/SoB
[2] https://salsa.debian.org/debian-gis-team/opencpn.git

-- 
http://fam-tille.de

Message #382 received at 538067-done@bugs.debian.org (full text, mbox, reply):

From: Paul Wise <pabs@debian.org>

To: 538067-done@bugs.debian.org

Subject: opencpn: ITP was completed

Date: Mon, 29 Jun 2020 12:03:04 +0800

[Message part 1 (text/plain, inline)]

Source: opencpn
Source-Version: 5.0.0+dfsg-1

opencpn was uploaded to Debian a while ago.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.