From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrew Hyatt Newsgroups: gmane.emacs.bugs Subject: bug#2491: 23.0.90; Flymake too aggressive when responding to unusual error combination Date: Mon, 25 Jan 2016 04:22:36 +0000 Message-ID: References: <20090227041420.3646.qmail@priss.frightenedpiglet.com> <87io2vd0bq.fsf@priss.frightenedpiglet.com> <87zivuguki.fsf@priss.frightenedpiglet.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1143fae0d10504052a20eba3 X-Trace: ger.gmane.org 1453695800 8391 80.91.229.3 (25 Jan 2016 04:23:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 04:23:20 +0000 (UTC) Cc: 2491@debbugs.gnu.org, rfrancoise@debian.org To: Derek Upham Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 25 05:23:13 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aNYgK-00016l-9A for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Jan 2016 05:23:12 +0100 Original-Received: from localhost ([::1]:34697 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNYgJ-0004Uh-3q for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Jan 2016 23:23:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNYgD-0004UN-38 for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2016 23:23:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNYg9-00019c-Pc for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2016 23:23:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNYg9-00019Y-MC for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2016 23:23:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aNYg9-00011E-Iz for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2016 23:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrew Hyatt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Jan 2016 04:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 2491 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 2491-submit@debbugs.gnu.org id=B2491.14536957753902 (code B ref 2491); Mon, 25 Jan 2016 04:23:01 +0000 Original-Received: (at 2491) by debbugs.gnu.org; 25 Jan 2016 04:22:55 +0000 Original-Received: from localhost ([127.0.0.1]:35362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNYg2-00010r-Jw for submit@debbugs.gnu.org; Sun, 24 Jan 2016 23:22:55 -0500 Original-Received: from mail-vk0-f48.google.com ([209.85.213.48]:33582) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNYg0-00010e-R0 for 2491@debbugs.gnu.org; Sun, 24 Jan 2016 23:22:53 -0500 Original-Received: by mail-vk0-f48.google.com with SMTP id e64so68369703vkg.0 for <2491@debbugs.gnu.org>; Sun, 24 Jan 2016 20:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=RDxIrPZORAsf+LpZqB2MCboeX7YOAPD/pKatPEfqor8=; b=QfJ3oIyPKFdVtgUiehEFBr4Ao3X5pcYtZbeMpah6ZybMnqh60Ld2kNFCvDd8IHhlcU iERqQZXYo9JKWknXPtxBgB37XVpC2c2raflCcN64NrX+c4Ruf/DgseM2SC72Zn9K0sgR AMqOLlu26Zq5Sz8BpDUmhBxbmzFpsM7HjHHzD4duHd3sRiCxHqH7RLVpCSxgJmppHAl+ sfHwGkx4Lq4dRzfkzS111cPu0NUicvY+se/y7gQ/LZUm/X+g28hEyY0bF58kSACWm7ny uvYSc5+rx9Vh+7EUlnKQaO5OyIIIpZG1zLe3MgsWdSdBDio0s0/gwFnOx7oyVQBx7V/N /kBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=RDxIrPZORAsf+LpZqB2MCboeX7YOAPD/pKatPEfqor8=; b=AybDy0SOsigVzZwSnghVhJNpcY3bf1/etqtqxv8UDlMRAesYpVim2Da9UD6EhVXqm7 kaJaIu+QWG1+9PqHrBMaGIMzmZ754eSG3QyMkc7sJveZE5mR+KjS4Xx4GidGavFcG5+l ne7sDH7KhPf+heZec4jWBNDKNohl5SyzDM2HnL9itqMA3y0SQLgjyUR6nN4WmjQPbh82 R5SokZ+ob6IYXJdNPlEIy+ziDlo8UdaXWoCudoF0x9HMMCyeVUImRAvjJygk6dsR6Rih Z+gYh8EJiaq+pQKHvGJXjLjmeUapoDdDmpw0FkZwhUYyC4KmtfUi6J1/6GC6OqWOSs9s eZoQ== X-Gm-Message-State: AG10YOQWVlZW4HrtoKIi+ZB63EmY3x5JSJbowg13AmFj6MVGJX6c2GK89Fkqr0HPPjQym5gRsRId76NekM85qA== X-Received: by 10.31.47.200 with SMTP id v191mr10043647vkv.116.1453695767215; Sun, 24 Jan 2016 20:22:47 -0800 (PST) In-Reply-To: <87zivuguki.fsf@priss.frightenedpiglet.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:111952 Archived-At: --001a1143fae0d10504052a20eba3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Derek. On Sun, Jan 24, 2016 at 11:19 PM Derek Upham wrote: > This many years down the line I=E2=80=99m not in a position to reproduce = it, so > just close it out as =E2=80=9Ccan=E2=80=99t repro=E2=80=9D. > > Thanks, > > Derek > > Andrew Hyatt writes: > > > Got it. So, if I understand correctly, this may or may not be fixed, > > but in any case, it seems specific to Erlang. Hopefully you, or anothe= r > > Erlang user, can attempt to reproduce it so that we can move forward on > > this bug. > > > > Derek Upham writes: > > > >> The situation is a flymake check for =E2=80=9Cfoo.c=E2=80=9D, where = =E2=80=9Cfoo.c=E2=80=9D is > perfectly fine but it #includes =E2=80=9Cbar.h=E2=80=9D which has a synta= x error. > >> > >> Flymake triggers a compilation. The compilation fails due to the > syntax error, returning a non-zero exit status, along with the text > >> > >> bar.h:30: error: Invalid syntax > >> > >> Flymake quietly drops any error messages that refer to anything other > than =E2=80=9Cfoo.c=E2=80=9D. As far as it is concerned, the above error= output is empty. > That means... > >> > >> - The error and warning counts are zero > >> - The exit status is non-zero > >> - The check was not interrupted > >> > >> The nested =E2=80=98if=E2=80=99 clauses in =E2=80=98flymake-post-synta= x-check=E2=80=99 route control > through: > >> > >> (flymake-report-fatal-status "CFGERR" > >> (format "Configuration error has occured while running %s" command)) > >> > >> This code reports a fatal error and permanently turns off Flymake in > the buffer. After you fix the syntax error in =E2=80=9Cbar.h=E2=80=9D, y= ou have to restart > Flymake in =E2=80=9Cfoo.c=E2=80=9D (and any other files that depended on = it). The bug is > that we need to explicitly restart Flymake. > >> > >> The proposed solution in the bug report is to treat this case as a > non-fatal situation, with a special mode line tag to indicate =E2=80=9Cth= ere=E2=80=99s a > deeper problem=E2=80=9D. (It would be great if we could point the user t= o an error > in =E2=80=9Cbar.h=E2=80=9D line 30, but I don=E2=80=99t think there=E2=80= =99s a good way to do it in the > UI.) Upon reflection, I think it=E2=80=99s better for Flymake to keep co= unts of > errors and warnings in =E2=80=9Cother=E2=80=9D files (not ignore them) an= d use that to > improve the post-syntax-check tests with another =E2=80=9Cif=E2=80=9D cla= use. > >> > >> (I=E2=80=99m pretty sure this was with Erlang code, which is why no on= e else > has encountered the bug. As I recall, GCC provides enough breadcrumbs th= at > the #include line in the .c file will be tagged as a problem. The Erlang > compiler doesn=E2=80=99t show that information, or didn=E2=80=99t back th= en.) > >> > >> Derek > >> > >> ahyatt@gmail.com writes: > >> > >>> Thanks for the bug report, and sorry it's sat so long without any > >>> movement. Looking over this, I don't particularly understand the issu= e > >>> (why would the check return a non-zero exit status if it was working > >>> properly?) It might help if you provided a simple example. > >>> > >>> I've looked at the code in Emacs 25, though, and it still has the log= ic > >>> you report. > >>> > >>> sand@blarg.net writes: > >>> > >>>> Background > >>>> ---------- > >>>> > >>>> The Flymake library shipped with CVS HEAD (and probably earlier) has > >>>> the following code in `flymake-post-syntax-check': > >>>> > >>>> (defun flymake-post-syntax-check (exit-status command) > >>>> ;; [. . . elided . . .] > >>>> > >>>> (if (and (equal 0 err-count) (equal 0 warn-count)) > >>>> (if (equal 0 exit-status) > >>>> (flymake-report-status "" "") ; PASSED > >>>> (if (not flymake-check-was-interrupted) > >>>> (flymake-report-fatal-status "CFGERR" > >>>> (format "Configuration error has occured while running %s" command)) > >>>> (flymake-report-status nil ""))) ; "STOPPED" > >>>> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) > >>>> > >>>> Depending on... > >>>> > >>>> ...whether the flymake check generated errors or warnings, > >>>> ...whether the flymake check had a non-zero exit status, and > >>>> ...whether we interrupted the flymake check, > >>>> > >>>> we can generate any of four different statuses. One of the statuses, > >>>> "CFGERR" is fatal, and turns off flymake for that buffer. The others > >>>> are non-fatal. > >>>> > >>>> Problem > >>>> ------- > >>>> > >>>> Flymake only tracks errors that refer to the specific file being > >>>> checked. For example, given the following output for "foo.c", > >>>> which includes file "bar.h" > >>>> > >>>> foo.c:20: warning: Type mismatch > >>>> bar.h:30: error: Invalid syntax > >>>> > >>>> Flymake would "see" one warning and no errors. The "bar.h" error is > >>>> dropped. Now consider the degenerate case where "bar.h" is the only > >>>> source of errors, *and the check returns a non-zero exit status*: > >>>> > >>>> bar.h:30: error: Invalid syntax > >>>> > >>>> The error and warning counts are zero, the exit status is non-zero, > >>>> the check was not interrupted, so we end up reporting a fatal CFGERR= . > >>>> > >>>> Think aobut the user experience here, with the two examples shown > >>>> above. First, Flymake checks, and reports an warning in the current > >>>> file "foo.c". The user fixes the warning. Then Flymake reports a > >>>> fatal error (popping up a dialog box under X) and turns itself off! > >>>> > >>>> Solution > >>>> -------- > >>>> > >>>> That particular code branch is supposed to catch cases where the bui= ld > >>>> system itself dies with an error, which is important to detect. But > >>>> shutting down Flymake is too excessive a response, because of errors > >>>> in included files. > >>>> > >>>> The following replacement code changes the behavior to report zero > >>>> errors and zero warnings with the file itself, but it adds a ":CFGER= R" > >>>> flag to indicate that there was some other problem with the check. > >>>> Flymake remains enabled for the buffer. > >>>> > >>>> (defun flymake-post-syntax-check (exit-status command) > >>>> ;; [. . . elided . . .] > >>>> > >>>> (if (and (equal 0 err-count) (equal 0 warn-count)) > >>>> (if (equal 0 exit-status) > >>>> (flymake-report-status "" "") ; PASSED > >>>> (if (not flymake-check-was-interrupted) > >>>> (flymake-report-status "0/0" ":CFGERR") > >>>> (flymake-report-status nil ""))) ; "STOPPED" > >>>> (flymake-report-status (format "%d/%d" err-count warn-count) ""))) > >>>> > >>>> > >>>> Derek > >>>> > >>>> > >>>> > >>>> > >>>> In GNU Emacs 23.0.90.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) > >>>> of 2009-02-07 on elegiac, modified by Debian > >>>> (emacs-snapshot package, version 1:20090207-1) > >>>> Windowing system distributor `The X.Org Foundation', version > 11.0.10402000 > >>>> configured using `configure '--build' 'i486-linux-gnu' '--host' > >>>> 'i486-linux-gnu' '--prefix=3D/usr' '--sharedstatedir=3D/var/lib' > >>>> '--libexecdir=3D/usr/lib' '--localstatedir=3D/var' > '--infodir=3D/usr/share/info' > >>>> '--mandir=3D/usr/share/man' > >>> '--with-pop=3Dyes' > >>> > '--enable-locallisppath=3D/etc/emacs-snapshot:/etc/emacs:/usr/local/share= /emacs/23.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/= 23.0.90/site-lisp:/usr/share/emacs/site-lisp' > >>> '--with-x=3Dyes' '--with-x-toolkit=3Dgtk' 'build_alias=3Di486-linux-g= nu' > 'host_alias=3Di486-linux-gnu' 'CFLAGS=3D-DDEBIAN -DSITELOAD_PURESIZE_EXTR= A=3D5000 > -g -O2' 'LDFLAGS=3D-g -Wl,--as-needed' 'CPPFLAGS=3D'' > > > -- > Derek Upham > sand@blarg.net > --001a1143fae0d10504052a20eba3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Derek.

On Sun, Jan 24, 2016 at 11:19 PM Derek Upham <sand@blarg.net> wrote:
This many years down the line I=E2=80=99m not in a position t= o reproduce it, so just close it out as =E2=80=9Ccan=E2=80=99t repro=E2=80= =9D.

Thanks,

Derek

Andrew Hyatt writes:

> Got it.=C2=A0 So, if I understand correctly, this may or may not be fi= xed,
> but in any case, it seems specific to Erlang.=C2=A0 Hopefully you, or = another
> Erlang user, can attempt to reproduce it so that we can move forward o= n
> this bug.
>
> Derek Upham <sa= nd@blarg.net> writes:
>
>> The situation is a flymake check for =E2=80=9Cfoo.c=E2=80=9D, wher= e =E2=80=9Cfoo.c=E2=80=9D is perfectly fine but it #includes =E2=80=9Cbar.h= =E2=80=9D which has a syntax error.
>>
>> Flymake triggers a compilation.=C2=A0 The compilation fails due to= the syntax error, returning a non-zero exit status, along with the text >>
>>=C2=A0 =C2=A0bar.h:30: error: Invalid syntax
>>
>> Flymake quietly drops any error messages that refer to anything ot= her than =E2=80=9Cfoo.c=E2=80=9D.=C2=A0 As far as it is concerned, the abov= e error output is empty.=C2=A0 That means...
>>
>> - The error and warning counts are zero
>> - The exit status is non-zero
>> - The check was not interrupted
>>
>> The nested =E2=80=98if=E2=80=99 clauses in =E2=80=98flymake-post-s= yntax-check=E2=80=99 route control through:
>>
>>=C2=A0 (flymake-report-fatal-status "CFGERR"
>>=C2=A0 =C2=A0(format "Configuration error has occured while ru= nning %s" command))
>>
>> This code reports a fatal error and permanently turns off Flymake = in the buffer.=C2=A0 After you fix the syntax error in =E2=80=9Cbar.h=E2=80= =9D, you have to restart Flymake in =E2=80=9Cfoo.c=E2=80=9D (and any other = files that depended on it).=C2=A0 The bug is that we need to explicitly res= tart Flymake.
>>
>> The proposed solution in the bug report is to treat this case as a= non-fatal situation, with a special mode line tag to indicate =E2=80=9Cthe= re=E2=80=99s a deeper problem=E2=80=9D.=C2=A0 (It would be great if we coul= d point the user to an error in =E2=80=9Cbar.h=E2=80=9D line 30, but I don= =E2=80=99t think there=E2=80=99s a good way to do it in the UI.)=C2=A0 Upon= reflection, I think it=E2=80=99s better for Flymake to keep counts of erro= rs and warnings in =E2=80=9Cother=E2=80=9D files (not ignore them) and use = that to improve the post-syntax-check tests with another =E2=80=9Cif=E2=80= =9D clause.
>>
>> (I=E2=80=99m pretty sure this was with Erlang code, which is why n= o one else has encountered the bug.=C2=A0 As I recall, GCC provides enough = breadcrumbs that the #include line in the .c file will be tagged as a probl= em.=C2=A0 The Erlang compiler doesn=E2=80=99t show that information, or did= n=E2=80=99t back then.)
>>
>> Derek
>>
>> ahyatt@gmail= .com writes:
>>
>>> Thanks for the bug report, and sorry it's sat so long with= out any
>>> movement. Looking over this, I don't particularly understa= nd the issue
>>> (why would the check return a non-zero exit status if it was w= orking
>>> properly?) It might help if you provided a simple example.
>>>
>>> I've looked at the code in Emacs 25, though, and it still = has the logic
>>> you report.
>>>
>>> sand@blarg= .net writes:
>>>
>>>> Background
>>>> ----------
>>>>
>>>> The Flymake library shipped with CVS HEAD (and probably ea= rlier) has
>>>> the following code in `flymake-post-syntax-check':
>>>>
>>>> (defun flymake-post-syntax-check (exit-status command)
>>>> ;; [. . . elided . . .]
>>>>
>>>> (if (and (equal 0 err-count) (equal 0 warn-count))
>>>> (if (equal 0 exit-status)
>>>> (flymake-report-status "" "") ; PASSED=
>>>> (if (not flymake-check-was-interrupted)
>>>> (flymake-report-fatal-status "CFGERR"
>>>> (format "Configuration error has occured while runnin= g %s" command))
>>>> (flymake-report-status nil ""))) ; "STOPPED= "
>>>> (flymake-report-status (format "%d/%d" err-count= warn-count) "")))
>>>>
>>>> Depending on...
>>>>
>>>> ...whether the flymake check generated errors or warnings,=
>>>> ...whether the flymake check had a non-zero exit status, a= nd
>>>> ...whether we interrupted the flymake check,
>>>>
>>>> we can generate any of four different statuses. One of the= statuses,
>>>> "CFGERR" is fatal, and turns off flymake for tha= t buffer. The others
>>>> are non-fatal.
>>>>
>>>> Problem
>>>> -------
>>>>
>>>> Flymake only tracks errors that refer to the specific file= being
>>>> checked. For example, given the following output for "= ;foo.c",
>>>> which includes file "bar.h"
>>>>
>>>> foo.c:20: warning: Type mismatch
>>>> bar.h:30: error: Invalid syntax
>>>>
>>>> Flymake would "see" one warning and no errors. T= he "bar.h" error is
>>>> dropped. Now consider the degenerate case where "bar.= h" is the only
>>>> source of errors, *and the check returns a non-zero exit s= tatus*:
>>>>
>>>> bar.h:30: error: Invalid syntax
>>>>
>>>> The error and warning counts are zero, the exit status is = non-zero,
>>>> the check was not interrupted, so we end up reporting a fa= tal CFGERR.
>>>>
>>>> Think aobut the user experience here, with the two example= s shown
>>>> above. First, Flymake checks, and reports an warning in th= e current
>>>> file "foo.c". The user fixes the warning. Then F= lymake reports a
>>>> fatal error (popping up a dialog box under X) and turns it= self off!
>>>>
>>>> Solution
>>>> --------
>>>>
>>>> That particular code branch is supposed to catch cases whe= re the build
>>>> system itself dies with an error, which is important to de= tect. But
>>>> shutting down Flymake is too excessive a response, because= of errors
>>>> in included files.
>>>>
>>>> The following replacement code changes the behavior to rep= ort zero
>>>> errors and zero warnings with the file itself, but it adds= a ":CFGERR"
>>>> flag to indicate that there was some other problem with th= e check.
>>>> Flymake remains enabled for the buffer.
>>>>
>>>> (defun flymake-post-syntax-check (exit-status command)
>>>> ;; [. . . elided . . .]
>>>>
>>>> (if (and (equal 0 err-count) (equal 0 warn-count))
>>>> (if (equal 0 exit-status)
>>>> (flymake-report-status "" "") ; PASSED=
>>>> (if (not flymake-check-was-interrupted)
>>>> (flymake-report-status "0/0" ":CFGERR"= )
>>>> (flymake-report-status nil ""))) ; "STOPPED= "
>>>> (flymake-report-status (format "%d/%d" err-count= warn-count) "")))
>>>>
>>>>
>>>> Derek
>>>>
>>>>
>>>>
>>>>
>>>> In GNU Emacs 23.0.90.1 (i486-pc-linux-gnu, GTK+ Version 2.= 12.11)
>>>> of 2009-02-07 on elegiac, modified by Debian
>>>> (emacs-snapshot package, version 1:20090207-1)
>>>> Windowing system distributor `The X.Org Foundation', v= ersion 11.0.10402000
>>>> configured using `configure '--build' 'i486-li= nux-gnu' '--host'
>>>> 'i486-linux-gnu' '--prefix=3D/usr' '--= sharedstatedir=3D/var/lib'
>>>> '--libexecdir=3D/usr/lib' '--localstatedir=3D/= var' '--infodir=3D/usr/share/info'
>>>> '--mandir=3D/usr/share/man'
>>> '--with-pop=3Dyes'
>>> '--enable-locallisppath=3D/etc/emacs-snapshot:/etc/emacs:/= usr/local/share/emacs/23.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/u= sr/share/emacs/23.0.90/site-lisp:/usr/share/emacs/site-lisp'
>>> '--with-x=3Dyes' '--with-x-toolkit=3Dgtk' '= ;build_alias=3Di486-linux-gnu' 'host_alias=3Di486-linux-gnu' &#= 39;CFLAGS=3D-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=3D5000 -g -O2' 'LDFL= AGS=3D-g -Wl,--as-needed' 'CPPFLAGS=3D''


--
Derek Upham
sand@blarg.net
--001a1143fae0d10504052a20eba3--