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
-- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/550dad9b.4060...@kalian.cz
