Dear Sean, Thank you for your comments.
>I'd recommend including the upstream code in the git repository, too. >But what you've done is fine -- thanks! I've now added that too. >> >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). I've done so, and autoreconf now runs successfully as part of the build process. >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. I've now worked around the kfreebsd hang (unfortunately Adam Borowski's fix didn't work for me). A comment today on debian-mentors suggested that claiming 'Architecture: any' was reasonable even if the remaining ports have not yet been tested... I've also added doc-base support. These changes are uploaded to https://github.com/dghart/4pane-debian-dir Regards, David Hart
