[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#832941: RFS: 4pane (debian: message 7 of 20)

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

Reply to: