On 20.09.2014 15:45, Tobias Frost wrote: [...] > The split is not under dispute. Other packages do that too, for example > redeclipse. But redeclipse do it "right" (in my view) and their > generate-copyright-script which is aware of the package it acts on. > (Your script can be enhanced to do that too. Probably less time effort > that I spent already on this topic.)
Redeclipse consists only of src:redeclipse and src:redeclipse-data. So in this case there is only *one* data package and naturally the generate-copyright-script acts only on this one. I agree with you that we both waste time here. I still think the comment in debian/copyright and the nature of the split would justify a "unified" d/copyright file but I intend to modify the script so that everyone's happy. [...] > I disagree. Having 6362* entries in d/copyright which does not match any > file is NOT accurate. To be very clear: I will NOT sign such a package > with my PGP key. > > (*6392 is the number of lintian > wildcard-matches-nothing-in-dep5-copyright messages, already music/ and > sound/ subtracted) Please note that's an informational warning and with the information given already, everyone knows that the three data packages should be seen as one package just split in three parts. > Due to the split I say "we now have 4 related, but independent source > packages and they should be handled as such". > The Relation is no guarantee that the packages will not diverge in the > future. (e.g code could go forward, while data keeps the same, or vice > verse) Nope, those packages will always be kept in sync with src:ufoai. They are not independent source packages and you should simply trust me with that statement. [...] >>> To make it clear: I require an 100% accurate d/copyright and this is one >>> of the few points that are not subject to negotiations. >> >> Absolutely. Could you elaborate on where a file is not accurately >> addressed by copyright format 1.0? > > > Who's the copyright owner of those? > base/models/objects/vegi/palm_v1/palm1.md2 | Creative Commons > Attribution-Share Alike 3.0 > base/models/objects/vegi/palm_v1/palm2.md2 | Creative Commons > Attribution-Share Alike 3.0 > base/models/objects/vegi/palm_v2/palm1.md2 | Cr.g teative Commons > Attribution-Share Alike 3.0 > base/models/objects/vegi/palm_v2/palm2.md2 | Creative Commons > Attribution-Share Alike 3.0 > > (if emtpy means upstream, UFO:AI Team is not in the list for that > license and its not GPL-2+. Either way, d/copyright is wrong here.) Empty means UFO:AI team. I will add this information more prominently to debian/copyright. > > contrib/7th.zip | | 2002 Iconian Fonts - Daniel Zadorozny - > http://www.iconian.com/ > contrib/scripts/compile_po.bat | | Kostia "Kildor" Romanov > contrib/scripts/update_potfiles_in.bat | | Kostia "Kildor" Romanov > > no such files -- LICENSE has "too many files" > > radiant/bitmaps/texwindow_uniformsize.png | | orbweaver (commiter in > darkradiant repository) | True. I removed those files. They are not part of the sources. [..l] > base/textures/tex_pics/art_africa008.png | Creative Commons > Attribution-Share Alike 3.0 | Udit Kulshrestha | > http://commons.wikimedia.org/wiki/File:Ole_Man.jpg > > Wikimedia says "Creative Commons Attribution-Share Alike 3.0 Unported" That's correct. It is CC-BY-SA-3.0 but that's the same information LICENSES gives you currently. "Unported" is implied see also the standalone paragraph. > > base/textures/tex_buildings/carpet024.png | GNU General Public License > 2.0 or later | MCR | > http://commons.wikimedia.org/wiki/File:42556-Antique-Persian-Tabriz-Carpets-hires.jpg > > Wikimedia says > GNU Free Documentation Licidenticalense, Version 1.2 (no invariant) or > any later version or CC-BY-SA-30 and author is Nazmiyal > > (Those were random picks out of the http-ones; to avoid the imopression > that everytghing is wrong: Its not, there are correct ones, which I did > not quote.) Those two files need to be investigated. [...] >> Sure I could duplicate the same code for every source package but what >> would we gain? Quality? Reduction of maintenance work? > > Come on... Above you say keeping 4 duplicated copyright files in sync is > fine and now you say you cannot handle to keep 4 identical > get-orig-targets snippets in sync? (The snippets could use, for example, > use the upstream version from d/changelog to get the right commmit -- > using the upstream tag and not the git commit id, then everything is > wonderful and likely never needs a change. > > I see all of the 4 source packages as related, but independent entities. I said I could duplicate the code but I feel that we gain nothing with it since I'm the only one who has to work with those packages. As long as it is not a Policy violation, I would prefer to make some independent decisions about maintaining my own packages. [...] > > Ok, lets leave that without +repack. > > (I still think people will have the expectation without it that they > will be able to find the orig.tar somewhere on the net "as is", > especially as there is no README.Source (but there will be one at the > point of upload, I guess.) I'm a little confused here because there are README.source files in all source packages but I intend to expand on their content. I don't see any reasons why people should assume that because they are expected to use the get-orig-source targets in src:ufoai. Regards, Markus
signature.asc
Description: OpenPGP digital signature
