Am Saturday, den 20.09.2014, 17:33 +0200 schrieb Markus Koschany: > On 20.09.2014 15:45, Tobias Frost wrote: > [...] > 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. As you extend your script those will gone too. > > > 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. Do you mean: You removed them manually? I didnt see any documentation; this must be explained in d/copyright. see also https://wiki.debian.org/BenFinney/software/repack: Debian Policy §12.5 says “… the copyright file must say where the upstream sources (if any) were obtained…”. This is commonly interpreted to imply that, if you re-pack the upstream source, the reason should be explained in the debian/copyright file. The machine-readable copyright file format specifies the free-form text of the “Source” field should be used for this purpose. > [...] > >> 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 tyou are free to look for some other sponsoro 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. According d/control this package is team maintained. > As long > as it is not a Policy violation, I would prefer to make some independent > decisions about maintaining my own packages. I'm not enforcing the decisions to you. You can still freely decide to change according to my request or not. But out of decissions follow consequences. Let me put this in some words, being very clear and very direct: The policy only describes a minimum set of rules. Best practice can go over this standards. The policy does not constitute a right for you to demand that I lower my standards in respect what I consider best practice, especially if you fail to convince me that you are right. If you cannot accept that, I will not the one sponsoring your uploads. Now, decide for the red or blue pill. > [... > > > > 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.) With the information that files are deleted, I have to revise my decission. Please let me know if the suffix will be +dsfg or +repack Depending on the reasons behind the repack. > 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 Let me know if we can proceed or not. -- Tobi
Attachment:
signature.asc
Description: This is a digitally signed message part