Bug#832941: RFS: 4pane
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
Reply to: