Bug#538067: status of the opencpn PPA for inclusion in Debian
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
Reply to: