Your message dated Sun, 30 Apr 2017 09:05:50 +0000 with message-id <e1d4kne-0000j5...@respighi.debian.org> and subject line unblock lintian has caused the Debian Bug report #861525, regarding unblock: lintian/2.5.50.2 to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 861525: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861525 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: release.debian.org Severity: normal User: release.debian....@packages.debian.org Usertags: unblock Please unblock package lintian The 2.5.50.2 unload works around a "perl stack" corruption (not to be confused with perl's C stack) and makes a gnuplot file compability with gnuplot 5 (so it works with the version we are shipping in stretch). I will expand on the stack corruption below in case it is relevant for your understanding of the issue and the fix[1]. That said, the fix is shorter than my explanation, so you may just want to skip ahead to the debdiff. unblock lintian/2.5.50.2 Thanks, ~Niels [1] Perl stack corruption ===================== For most runs, "perl stack" corruption occurs but perl never notices it until it has to unwind the stack to the point of the corruption. On a successful run, the lintian tools will always exit from their main sub and therefore avoid the issue. To reproduce this bug, you will have to cause the tool to throw an exception that generates a stack trace (or unwinds past the main sub). That is very trivial to do with the reporting framework (but could in theory happen in lintian-info and lintian-lab-tool). It cannot be reproduced in lintian itself. Lintian 2.5.50.2 is started via an "exec" call after the stack corruption, so lintian cannot unwind to the corrupted stack. To reproduce, install lintian 2.5.50.1 and run: """ $ mkdir empty-dir $ /usr/share/lintian/frontend/dplint reporting-sync-state \ --state-dir empty-dir \ --mirror-path /value-does-not-matter \ --distributions value-does-not-matter \ --architectures value-does-not-matter \ --mirror-areas value-does-not-matter \ --desired-version 2.5.50.1 Can't locate object method "errno" via package "Bizarre copy of ARRAY in list assignment at /usr/share/perl/5.24/Carp.pm line 229. " (perhaps you forgot to load "Bizarre copy of ARRAY in list assignment at /usr/share/perl/5.24/Carp.pm line 229. "?) at /usr/share/perl5/Lintian/Util.pm line 1614. """ The output here is a "double fault". First, perl notices the corruption and throws a string exception with the text: "Bizarre copy of ARRAY in list assignment at /usr/share/perl/5.24/Carp.pm line 229.\n" Lintian catches this assuming it is an autodie exception and then tries to call the "errno" method on it. Obviously this fails again leading to the weird error message. The work around for this is to avoid passing the "@ARGV" variable on the stack (i.e. passing as an argument to a perl sub). That way, the perl stack is not corrupted when Getopt::Long parses the options. Thanks, ~Niels
--- End Message ---
--- Begin Message ---Unblocked lintian.
--- End Message ---
