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
Attachment:
signature.asc
Description: This is a digitally signed message part