Dear David, A few comments on your reply. On Fri, Sep 30, 2016 at 03:40:33PM +0100, David Hart wrote: > >2. Why doesn't 4pane work on archs other than i386, amd64, hurd-i386? > I didn't think it would. However after discussion on debian-mentors I've now > shown it works on armel, and it builds on kfreebsd-amd64 but immediately hangs > in a forkpty call; I'll try to debug that when I have time. I expect some or > all of the other archs will also build. If/when 4pane attracts a sponsor I'll > try them. Debian packages need to work on all our release architectures unless there is some fundamental fact about the package that prevents it (e.g. a tool for analysing machine code on a particular arch). Note that kfreebsd-amd64 is not a release architecture anymore. > >4 I think that it would be clearer to express the wxWindows license as a > >dual-license: "GPL-2+ or wxWindows", with separate license paragraphs for each > >of those. > I'm not sure I understand. wxWidgets isn't dual-licensed, it uses just the > wxWindows license which, though similar to GPL-2, is different. I might be missing something, but the text of the license says: - you can use the library under the GPL-2 or later - you can use the library under wxWindows License 3.1 or later - if you add other GPL code to the library you can no longer distribute under the wxWindows License - if you make modifications you can continue the dual-licensing or not The 3rd and 4th points follow from the 1st and 2nd, so all the license is actually saying is the 1st and 2nd, i.e., a dual license under GPL-2+ and wxWindows-3.1+. > > Of your suggestions, 2, 3, 5, and 7-9 are now implemented. Of the > others that need a comment: > > >1 I'd be very grateful if you'd put this source package in a git repository. > I presume you mean just the contents of debian/. I've done this: > https://github.com/dghart/4pane-debian-dir I'd recommend including the upstream code in the git repository, too. But what you've done is fine -- thanks! > >6. Can Vcs-Git: use a secure protocol? https:// rather than git://. > I don't think so, not without the user logging in to sourceforge. Fair enough. > >11. I'm not familiar with wxWidgets practices, but is it unavoidable to > >include sections of code from the wxWidgets sources... > It's not at all normal, but I have to do it in two places: > First, originally the main display widget was effectively unsubclassable and > even now it would be very hard. I hope to replace the control with one new in > wx3.0 when I no longer support wx2.8. Second, wxWidgets' inotify wrapper is new > in wx3.0; I've copied some of the code for use in earlier versions. Sounds reasonable, though, I'm not a C++ programmer. Hopefully someone else on d-mentors will comment. > >12. Please consider using dh_autoreconf to ensure that the package's > >build system can be reproduced from the source code provided > If I understand dh_autoreconf correctly, it can't: a fresh autoconf call will > fail as the package doesn't include various non-standard .m4 macros and such. > That could be fixed by a largish patch, but I'll leave it to a sponsor to > decide. In that case, this is now a "must-fix". The build system is part of the source package, so the source code for that build system must be included, to satisfy DFSG. You need to include those macros (or switch to use standard ones). It is not required to run dh_autoreconf: it is sufficient to include everything that would be needed to reconfigure. However, it is strongly recommended that you actually reconf, because it proves that all the required source code is actually present. Further, running dh_autoreconf can uncover bugs in the build system. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature