Today's bzr doesn't bootstrap

Today's bzr doesn't bootstrap

[Eli Zaretskii]

This is on GNU/Linux:

  Compiling progmodes/modula2.el

  In toplevel form:
  progmodes/modula2.el:113:1:Error: Adjacent non-terminals: proctype PROCEDURE-type
  make[3]: *** [progmodes/modula2.elc] Error 1

I tried to bootstrap because I had a similar problem in octave-inf.el
during a normal build (both on MS-Windows and on GNU/Linux):

  Compiling progmodes/octave-inf.el...

  In toplevel form:
  progmodes/octave-inf.el:30:1:Error: Adjacent non-terminals: exp do

Both of these have something to do with SMIE, AFAICT.

Am I doing something wrong?

Re: Today's bzr doesn't bootstrap

[Andrea Crotti]

Il giorno 24/giu/2011, alle ore 12.24, Eli Zaretskii ha scritto:

> This is on GNU/Linux:
> 
>  Compiling progmodes/modula2.el
> 
>  In toplevel form:
>  progmodes/modula2.el:113:1:Error: Adjacent non-terminals: proctype PROCEDURE-type
>  make[3]: *** [progmodes/modula2.elc] Error 1
> 
> I tried to bootstrap because I had a similar problem in octave-inf.el
> during a normal build (both on MS-Windows and on GNU/Linux):
> 
>  Compiling progmodes/octave-inf.el...
> 
>  In toplevel form:
>  progmodes/octave-inf.el:30:1:Error: Adjacent non-terminals: exp do
> 
> Both of these have something to do with SMIE, AFAICT.
> 
> Am I doing something wrong?
> 

I have the same problem on OSX, and since I needed it working fast I
temporarily solved moving octave-inf.el to octave-inf.el.bak if I remember correctly...
I tried to understand what that error means but at that line there's a deconst which looks perfectly normal to me.

Re: Today's bzr doesn't bootstrap

[Jashy]

Seemly the problem was introduced in rev 104693 from Stefan, you can revert
to 104594(bzr revert -r 104594 lisp/emacs-lisp/smie.el) and make boostrap
again.


Eli Zaretskii wrote:
> 
> This is on GNU/Linux:
>   Compiling progmodes/modula2.el
>   In toplevel form:
>   progmodes/modula2.el:113:1:Error: Adjacent non-terminals: proctype
> PROCEDURE-type
>   make[3]: *** [progmodes/modula2.elc] Error 1
> 
> 

-- 
View this message in context: http://old.nabble.com/Today%27s-bzr-doesn%27t-bootstrap-tp31918755p31925922.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Today's bzr doesn't bootstrap

[Eli Zaretskii]

> Date: Sat, 25 Jun 2011 06:08:49 -0700 (PDT)
> From: Jashy <nanjunjie@gmail.com>
> 
> 
> Seemly the problem was introduced in rev 104693 from Stefan, you can revert
> to 104594(bzr revert -r 104594 lisp/emacs-lisp/smie.el) and make boostrap
> again.

Thanks.  It's easy enough to work around this without reverting that
commit (just copy .el to .elc), and since I don't use Modula2, I can
patiently wait for Stefan or someone else to fix this.

This is bug#8934 now, by the way.

Re: Today's bzr doesn't bootstrap

[Glenn Morris]

Jashy wrote:

> Seemly the problem was introduced in rev 104693 

There is no need for these kind of reports any more, because this:

http://lists.gnu.org/archive/html/emacs-buildstatus/2011-06/msg00011.html

and this

http://hydra.nixos.org/build/1132466

tell us this automatically.

Automated builds

[Stefan Monnier]

>> Seemly the problem was introduced in rev 104693 

> There is no need for these kind of reports any more, because this:
> http://lists.gnu.org/archive/html/emacs-buildstatus/2011-06/msg00011.html
> and this
> http://hydra.nixos.org/build/1132466
> tell us this automatically.

Indeed.  And the next step for me in this line is for those build
reports to automatically open and close bug-reports (ideally, the
subject of the bug-report should be the error message pertaining to the
problem, which in general can't be obtained automatically, but in many
cases it shouldn't be that hard to find it by diffing the output
against last successful build and looking for "error" in the new part
of the output).


        Stefan

Re: Automated builds

[Glenn Morris]

Stefan Monnier wrote:

> Indeed.  And the next step for me in this line is for those build
> reports to automatically open and close bug-reports

Is that really worth it? These are all transient errors with no danger
of anyone forgetting to fix them. Once fixed, they are generally of no
further interest. Why clutter up the bug tracker with them? It seems
easy to see if the last mail in the buildstatus list has "failed" in the
subject, or to look at the hydra summary page. Having a bug seems no
easier to me.