Hi Vincent, On 08.07.2014 07:47, Vincent Cheng wrote: [...] > I'd be willing to sponsor this, although I don't have time to do a > thorough review right now (i.e. if any other DD is interested in > sponsoring ufoai, please go ahead, otherwise I'll get around to it > myself eventually...). Can you add it to the team sponsors queue in > the meantime? Thanks for your interest in this package and your continued support. Dmitry Smirnov also contacted me and he seemed interested in helping out too (however he mentioned the same restrictions as you :) ). The ufoai source package is rather complex and the -data packages quiet simple from a packaging point of view. The license review for the packages might be more demanding but I have written a small script that does the main part already. Perhaps one of you could check the technical aspects and the other one the license aspects, that would certainly speed things up? > A few questions/comments just from skimming your packaging: > - Is it worth building that many binary packages from src:ufoai? (I > haven't actually tried building this myself yet and I don't know how > large the resulting binary packages are, just asking.) Why not combine > ufoai-common + ufoai-misc, Good point here. I also thought long about that one. My argument here is that people who install the dedicated server don't need the language files and documentation (ufoai-misc). The package has an uncompressed size of 13,1 MB. In the future this data might grow and server admins would get even more unneeded data hence I decided to split it into a separate package. At the moment the packaging is optimized for this use case (only install data which is really needed). However if we want to save one binary package, we could merge both of them. > or ufoai-uforadiant + ufoai-tools? ufoai-uforadiant is the map editor and ufoai-tools contains three binaries + man pages which are a requirement to compile ufoai-data and ufoai-maps. Since the map editor is not required to build the other packages and it is something that is usually worth a separate source package, I split them off. > - debian/copyright: the GPL-2/GPL-3 license blocks should contain the > notice described in the appendix/"How to Apply These Terms to Your New > Programs" section, starting from "This program is free software...", > not just a pointer to /usr/share/common-licenses. Puh, I started to use the shorter paragraphs when I saw that some DDs did the same in the past. I think that a machine-readable paragraph like License: GPL-3+ On Debian systems, the complete text of the GNU General Public License version 3 can be found in "/usr/share/common-licenses/GPL-3". should be enough since the GPL is the most widely used license in the archive and copying more lines than needed over and over again does not serve a real purpose IMHO. It's painful enough that I have to copy the CC-BY and CC-BY-SA licenses again and again. I also believe the Policy supports my view here: §12.5: https://www.debian.org/doc/debian-policy/ch-docs.html "Packages distributed under the Apache license (version 2.0), the Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should refer to the corresponding files under /usr/share/common-licenses,[118] rather than quoting them in the copyright file. " But I guess the copyright file won't mind since it is already 400kb large... Thanks for your feedback. If you intend to sponsor the packages, please ignore what I've written above. It would be my pleasure to copy the whole GPL. :P Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature