• [PATCH] dpkg-buildpackage: print message on signal

    From [email protected]@21:1/5 to All on Fri Dec 13 11:30:01 2024
    From: Jochen Sprickerhof <[email protected]>

    We found a unit test in the gcc package that killed dpkg-buildpackage (#1089007). The error message was non obvious, so this adds a warning in
    case someone stumbles of over this again.
    ---
    scripts/dpkg-buildpackage.pl | 7 +++++++
    1 file changed, 7 insertions(+)

    diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
    index d849d6e90..4eadb5e7c 100755
    --- a/scripts/dpkg-buildpackage.pl
    +++ b/scripts/dpkg-buildpackage.pl
    @@ -20,6 +20,7 @@
    # You should have received a copy of the GNU General Public License
    # along with this program. If not, see <https://www.gnu.org/licenses/>.

    +use sigtrap 'handler' => \&sig_handler, 'normal-signals';
    use strict;
    use warnings;

    @@ -52,6 +53,12 @@ use Dpkg::Vendor qw(run_vendor_hook);

    textdomain('dpkg-dev');

    +sub sig_handler {
    + my $sig_name = shift;
    + print g_("$0 was killed by signal $sig_name.\n");
    + print g_("This is probably a bug in the package.\n");
    +}
    +
    sub showversion {
    printf g_("Debian %s version %s.\n"), $Dpkg::PROGNAME, $Dpkg::PROGVERSION;

    --
    2.45.2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to [email protected] on Fri Dec 13 13:20:01 2024
    Hi,

    On 12/13/24 19:22, [email protected] wrote:

    +use sigtrap 'handler' => \&sig_handler, 'normal-signals';

    This only handles HUP, INT, PIPE, TERM -- signals that I would expect do
    not indicate a problem in the package itself in most of the cases, and
    that I *do* want to abort the package build for (like the user pressing Ctrl-C).

    Things like SEGV, BUS, FPE are probably more along the line of "unexpected."

    +sub sig_handler {
    + my $sig_name = shift;
    + print g_("$0 was killed by signal $sig_name.\n");
    + print g_("This is probably a bug in the package.\n");
    +}

    That handler does not terminate dpkg-buildpackage, and does not stop the
    build. For some signals, I believe it should.

    Simon

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to [email protected] on Tue Dec 17 04:50:01 2024
    Hi!

    On Fri, 2024-12-13 at 11:22:59 +0100, [email protected] wrote:
    We found a unit test in the gcc package that killed dpkg-buildpackage (#1089007). The error message was non obvious, so this adds a warning in
    case someone stumbles of over this again.

    As discussed on IRC when this was sent, this looked to me like it
    would at least benefit from sbuild giving detailed information about dpkg-buildpackage exit condition, which Johannes Schauer Marin Rodrigues improved in sbuild commit 8bfae61a0826aa34ccdcc6ad48743e276716da4c.

    Then I mentioned whether dpkg-buildpackage could provide even more
    information, such as the PID and UID for the process emitting such
    terminating signal, which we could do via sigaction's SA_SIGINFO.

    One question though, was whether it makes sense for dpkg-buildpackage
    to try to self report, as it will be unable to do that for example for
    signals that cannot be caught. And in the end it looks like this is
    best done from the parent driving its invocation, and where the
    specific condition that triggered this problem seems extremely unusual
    (a child committing a parricide).

    So I think after having thought about this a bit more, it looks like
    this is better done elsewhere (which we have now). Thanks for the patch
    though!

    Regards,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)