Re: 5.0.2-test-2 is available

Re: 5.0.2-test-2 is available

[Peter Stephenson]

I'm getting with make on Cygwin

sh: colcrt: command not found
fgets: No error
Error reading man page /cygdrive/d/pstephen/code/Doc/./zshbuiltins.1
No manual entry for ./zshbuiltins.1
helpfiles: piping from man ./zshbuiltins.1 failed
Makefile:335: recipe for target `help.txt' faield
make[1]: *** [help.txt] Error 1
make[1]: Leaving directory `/cygdrive/pstephen/doc/Doc'
Makefile:189: recipe for target `all' failed

This can be suppressed but it's probably not obvious how to most people
at the moment.  It would good to render this harmless --- the helpfiles
aren't crucial.

pws

Re: 5.0.2-test-2 is available

[Bart Schaefer]

On Dec 2,  4:08pm, Peter Stephenson wrote:
}
} I'm getting with make on Cygwin
} 
} sh: colcrt: command not found

Out of curiosity, do you have yodl installed on Cygwin?  If not, how are
you even getting this far in the build process?  zshbuiltins.1 should
not exist, so the dependency for help.txt can't be satisfied, and perl
should never even be run ...?

If you don't have yodl, and zshbuiltins.1 is coming from the doc tarball,
then as noted in earlier email help.txt should also be in the doc tarball
and needs to be newer than zshbuiltins.1 so that it's not rebuilt.

If you do have yodl and are not using the doc tarball, then our previous
position has been that developers are responsible for making sure they have
all the tools to complete the build from scratch on whatever platform.

However, if we want to take the position that failing to rebuild help.txt
is inconsequential, then just remove the "false;" at the end of the rule
as in the following diff:


diff --git a/Doc/Makefile.in b/Doc/Makefile.in
index 50e210f..be66862 100644
--- a/Doc/Makefile.in
+++ b/Doc/Makefile.in
@@ -191,7 +191,7 @@ help.txt: zshbuiltins.1
 	@-rm -f $(sdir)/help.txt $(sdir)/help/*
 	perl $(sdir_top)/Util/helpfiles \
 	    $(sdir)/zshbuiltins.1 $(sdir)/help $(sdir)/help.txt \
-	    || { rm -f $(sdir)/help.txt $(sdir)/help/*; false; }
+	    || rm -f $(sdir)/help.txt $(sdir)/help/*
 
 $(MAN): zmacros.yo zman.yo
 

Re: 5.0.2-test-2 is available

[Peter Stephenson]

On Mon, 02 Dec 2013 08:36:01 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:

 On Dec 2,  4:08pm, Peter Stephenson wrote:
> }
> } I'm getting with make on Cygwin
> } 
> } sh: colcrt: command not found
> 
> Out of curiosity, do you have yodl installed on Cygwin?  If not, how are
> you even getting this far in the build process?  zshbuiltins.1 should
> not exist, so the dependency for help.txt can't be satisfied, and perl
> should never even be run ...?

At some point you get empty files called zshbuiltins.1 etc. created.

> If you do have yodl and are not using the doc tarball, then our previous
> position has been that developers are responsible for making sure they have
> all the tools to complete the build from scratch on whatever platform.

That doesn't really work with colcrt (or col) --- it's one of a possible
of set of tools varying by what the local manual system provides.
There's a variability here there isn't with Yodl and I don't feel like
fixing things up for every variant on the planet.

However, using the Doc bundle would probably be a good enough fix in
practice.  I should probably check that doesn't produce idiosyncracices
with helpfiles on Cygwin.

Of course, using Yodl throughout would be the right fix, but I haven't
heard anybody thinking about that.

pws

Re: 5.0.2-test-2 is available

[Bart Schaefer]

On Dec 2,  4:51pm, Peter Stephenson wrote:
} Subject: Re: 5.0.2-test-2 is available
}
} > Out of curiosity, do you have yodl installed on Cygwin?  If not, how are
} > you even getting this far in the build process?  zshbuiltins.1 should
} > not exist, so the dependency for help.txt can't be satisfied, and perl
} > should never even be run ...?
} 
} At some point you get empty files called zshbuiltins.1 etc. created.

Aha; that's because "yodl" has been replaced by ": yodl" and the build
system looks for that and creates empty files so that "make" won't exit
early when yodl is not installed.  I suspect this could be cleaned up a
different way, but it's a bit late for that for 5.0.3.

Did you try the patch that simply removes the "false;" from the help.txt
rule?  Doesn't suppress the "command not found" output etc. but ...

Re: 5.0.2-test-2 is available

[Peter Stephenson]

On Mon, 02 Dec 2013 09:31:10 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Did you try the patch that simply removes the "false;" from the help.txt
> rule?  Doesn't suppress the "command not found" output etc. but ...

I think so, since it's now complaining about zsh.texi owing to the lack
of Yodl.

pws

Re: 5.0.2-test-2 is available

[Peter Stephenson]

On Mon, 02 Dec 2013 16:51:37 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> However, using the Doc bundle would probably be a good enough fix in
> practice.  I should probably check that doesn't produce idiosyncrasies
> with helpfiles on Cygwin.

That seems to work OK; no problem on a random Cygwin installation.

It seems to me we should be more upfront about this in the INSTALL file,
as below.

Am I waiting for anything else before 5.0.3?

diff --git a/INSTALL b/INSTALL
index f4b09e0..00791cd 100644
--- a/INSTALL
+++ b/INSTALL
@@ -13,6 +13,26 @@ instructions in the first.
 MAKING AND INSTALLING
 =====================
 
+Dependencies
+------------
+
+The main shell can be compiled with tools available on a typical
+Unix-like system including development packages.  However, the
+documentation requires various additional tools that are not so standard:
+
+- YODL, for turning the documentation source files (.yo) into manual
+pages and TeXinfo source for producing PDF and .info formats;
+
+- Perl and interactive manual tools, for turning the zshbuiltins(1)
+manual into help files that can be displayed by the run-help function.
+For example, the colcrt or col tool, not typically required for
+installing software, must be available.
+
+To avoid needing these, the source distribution is supplemented by a
+documentation distribution that may be downloaded from the same place as
+the source.  This provides fully generated documentation with references
+to files in the default locations.
+
 Check MACHINES File
 -------------------
 
-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: 5.0.2-test-2 is available

[Bart Schaefer]

On Dec 8,  8:22pm, Peter Stephenson wrote:
}
} Am I waiting for anything else before 5.0.3?

There is the remaining bug that "setopt monitor" in a shell that did
not begin with it set, can cause an infinite loop.  However, that's
been a problem for many releases now so probably no need to wait.

Re: 5.0.2-test-3, arithmetic on pointer to void

[pda]

It seems I'm the only one not exclusively using gcc, although I admit I
use it more often than not too.  Just noticed the following with HP's C
compiler (and for the record, it even has -Agcc flag that accepts the code).

Creating "init.c", line 287: error #3143: arithmetic on pointer to void or function type
      void *ptr = base + (optno < 0 ? -optno : optno);
                       ^
1 error detected in the compilation of "init.c".

Re: 5.0.2-test-3, arithmetic on pointer to void

[Bart Schaefer]

On Dec 10,  3:21am, pda@sdf.org wrote:
}
} Creating "init.c", line 287: error #3143: arithmetic on pointer to void or function type
}       void *ptr = base + (optno < 0 ? -optno : optno);
}                        ^

As far as I can tell parseopts_insert is always passed a char* as base.
Might as well declare it for the way it's called rather than for the way
the pointer is used internally.

diff --git a/Src/init.c b/Src/init.c
index 7032ff8..53c4fbd 100644
--- a/Src/init.c
+++ b/Src/init.c
@@ -281,7 +281,7 @@ parseargs(char **argv, char **runscript)
 
 /**/
 static void
-parseopts_insert(LinkList optlist, void *base, int optno)
+parseopts_insert(LinkList optlist, char *base, int optno)
 {
     LinkNode node;
     void *ptr = base + (optno < 0 ? -optno : optno);

Re: 5.0.2-test-2 is available

[Bart Schaefer]

On Dec 2,  8:36am, Bart Schaefer wrote:
}
} However, if we want to take the position that failing to rebuild help.txt
} is inconsequential, then just remove the "false;" at the end of the rule
} as in the following diff:

Given the later recollection about an empty zshbuiltins.1 being created,
do we want to have this rule succeed with an empty help.txt as well?

Re: Test suite failures on static build (was: 5.0.2-test-2 is available)

[Axel Beckert]

Hi Peter,

On Mon, Dec 02, 2013 at 04:01:33PM +0000, Peter Stephenson wrote:
> On Mon, 02 Dec 2013 16:51:19 +0100
> Axel Beckert <abe@deuxchevaux.org> wrote:
> > JFTR: Probably not that important, but I get the following test-suite
> > failures when doing a static build:
> > Error output:
> > (eval):pushd:5: no such file or directory: /home/abe/zsh/zsh/obj-static/testhome
> > (eval):pushd:9: no such file or directory: /home/abe/zsh/zsh/obj-static/testhome
> > (eval):popd:10: directory stack empty
> > Was testing: PUSHD_TO_HOME option
> 
> Could the exported value of HOME be funny?

I don't think so:

~/zsh/zsh → echo $HOME
/home/abe
~/zsh/zsh → 

And it wasn't an automatic build but a debian package build in my
normal shell environment. Connected terminal and no chroot or other
fancy stuff. And it builds first a dynamically linked zsh and then a
statically linked zsh and the test suite only fails in the later case.

> (Sorry, should have told people to reply to zsh-workers with detailed
> reports.)

Ah, I could have guessed that myself, too. Moving over to -workers.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Test suite failures on static build (was: 5.0.2-test-2 is available)

[Peter Stephenson]

On Mon, 02 Dec 2013 17:16:17 +0100
Axel Beckert <abe@deuxchevaux.org> wrote:
> On Mon, Dec 02, 2013 at 04:01:33PM +0000, Peter Stephenson wrote:
> > On Mon, 02 Dec 2013 16:51:19 +0100
> > Axel Beckert <abe@deuxchevaux.org> wrote:
> > > JFTR: Probably not that important, but I get the following test-suite
> > > failures when doing a static build:
> > > Error output:
> > > (eval):pushd:5: no such file or directory: /home/abe/zsh/zsh/obj-static/testhome
> > > (eval):pushd:9: no such file or directory: /home/abe/zsh/zsh/obj-static/testhome
> > > (eval):popd:10: directory stack empty
> > > Was testing: PUSHD_TO_HOME option
> > 
> > Could the exported value of HOME be funny?
> 
> I don't think so:

Does this patch help anyway?  It leaves less to chance.

It won't help with the first problem, which could also be to do with
directory permissions or similar.

(Kind of me to make all the glob tests here rather brittle.)

diff --git a/Test/E01options.ztst b/Test/E01options.ztst
index e00eb0e..dc3ca4b 100644
--- a/Test/E01options.ztst
+++ b/Test/E01options.ztst
@@ -83,12 +83,13 @@
 %prep
   mkdir options.tmp && cd options.tmp
 
-  mkdir tmpcd
+  mkdir tmpcd homedir
 
   touch tmpfile1 tmpfile2
 
   mydir=$PWD
   mydirt=`print -P %~`
+  mydirhome=`export HOME=$mydir/homedir; print -P %~`
   catpath=$(which cat)
   lspath==ls
 
@@ -513,10 +514,10 @@
   print *(#q:s/#(#b)tmp(*e)/'scrunchy${match[1]}'/)
   unsetopt histsubstpattern
 0:HIST_SUBST_PATTERN option
->TINGcd TINGfile1 TINGfile2
+>TINGcd TINGfile1 TINGfile2 homedir
 >THUMPcd THUMPfile1 THUMPfile2
 >one.c Two.X Three.X
->scrunchyfile1 scrunchyfile2 tmpcd
+>homedir scrunchyfile1 scrunchyfile2 tmpcd
 
   setopt ignorebraces
   echo X{a,b}Y
@@ -853,6 +854,7 @@
 
 # Do you have any idea how dull this is?
 
+  (export HOME=$mydir/homedir
   pushd $mydir/tmpcd
   pushd
   dirs
@@ -863,11 +865,11 @@
   popd
   pushd
   popd
-  dirs
+  dirs)
 0q:PUSHD_TO_HOME option
->$mydirt $mydirt/tmpcd
->~ $mydirt $mydirt/tmpcd
->$mydirt
+>$mydirhome $mydirhome/tmpcd
+>~ $mydirhome $mydirhome/tmpcd
+>$mydirhome
 
   array=(one two three four)
   setopt rcexpandparam


pws

Re: Test suite failures on static build (was: 5.0.2-test-2 is available)

[Bart Schaefer]

On Dec 2,  5:16pm, Axel Beckert wrote:
} 
} On Mon, Dec 02, 2013 at 04:01:33PM +0000, Peter Stephenson wrote:
} > On Mon, 02 Dec 2013 16:51:19 +0100
} > Axel Beckert <abe@deuxchevaux.org> wrote:
} > > JFTR: Probably not that important, but I get the following test-suite
} > > failures when doing a static build:
} > > Error output:
} > > (eval):pushd:5: no such file or directory: /home/abe/zsh/zsh/obj-static/testhome
} > 
} > Could the exported value of HOME be funny?
} 
} I don't think so:

I can't come up with any other explanation for this, either.  There is
nowhere in the normal zsh "make" process that would reference a "testhome"
path.  *Something* is exporting that into the environment.

Re: Test suite failures on static build (was: 5.0.2-test-2 is available)

[Axel Beckert]

Hi,

On Mon, Dec 02, 2013 at 08:43:29AM -0800, Bart Schaefer wrote:
> } On Mon, Dec 02, 2013 at 04:01:33PM +0000, Peter Stephenson wrote:
> } > On Mon, 02 Dec 2013 16:51:19 +0100
> } > Axel Beckert <abe@deuxchevaux.org> wrote:
> } > > JFTR: Probably not that important, but I get the following test-suite
> } > > failures when doing a static build:
> } > > Error output:
> } > > (eval):pushd:5: no such file or directory: /home/abe/zsh/zsh/obj-static/testhome
> } > 
> } > Could the exported value of HOME be funny?
> } 
> } I don't think so:
> 
> I can't come up with any other explanation for this, either.  There is
> nowhere in the normal zsh "make" process that would reference a
> "testhome" path.  *Something* is exporting that into the
> environment.

Ah, thanks for that hint. I was looking at the wrong place, sorry.

The build scripts for the Debian package indeed change $HOME for the
test-suite:

HOME="$(CURDIR)/obj-static/testhome" dh_auto_test -B obj-static --parallel || true

But they do it also for the dynamically linked build where everything
seems to go fine:

HOME="$(CURDIR)/obj/testhome" dh_auto_test -B obj --parallel

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

[seems solved] Re: Test suite failures on static build (was: 5.0.2-test-2 is available)

[Axel Beckert]

Hi again,

On Mon, Dec 02, 2013 at 05:48:11PM +0100, Axel Beckert wrote:
> > I can't come up with any other explanation for this, either.  There is
> > nowhere in the normal zsh "make" process that would reference a
> > "testhome" path.  *Something* is exporting that into the
> > environment.
> 
> Ah, thanks for that hint. I was looking at the wrong place, sorry.
> 
> The build scripts for the Debian package indeed change $HOME for the
> test-suite:
> 
> HOME="$(CURDIR)/obj-static/testhome" dh_auto_test -B obj-static --parallel || true
> 
> But they do it also for the dynamically linked build where everything
> seems to go fine:
> 
> HOME="$(CURDIR)/obj/testhome" dh_auto_test -B obj --parallel

And indeed, somewhere else in the build scripts for the package
obj/testhome was created, but obj-static/testhome.

Thanks for the help and sorry for the noise.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

One test suite failure left on static build (after $HOME has been fixed)

[Axel Beckert]

Hi again,

the testhome related test-suite failures are now gone. Seems to have
been some legacy code in packaging which wasn't prepared to also run
the test suite for static builds -- which I introduced a few uploads
ago.

On Mon, Dec 02, 2013 at 05:57:45PM +0100, Axel Beckert wrote:
> > The build scripts for the Debian package indeed change $HOME for the
> > test-suite:
> > 
> > HOME="$(CURDIR)/obj-static/testhome" dh_auto_test -B obj-static --parallel || true

Leaves this test suite error:

../../Test/C02cond.ztst: starting.
Test ../../Test/C02cond.ztst failed: bad status 1, expected 0 from:
  if (( EUID == 0 )); then
    print -u$ZTST_fd 'Warning: Not testing [[ ! -r file ]] (root reads anything)'
    [[ -r zerolength && -r unmodish ]]
  elif [[ $OSTYPE = cygwin ]]; then
    print -u$ZTST_fd 'Warning: Not testing [[ ! -r file ]]
   (all files created by user may be readable)'
   [[ -r zerolength ]]
  else
    [[ -r zerolength && ! -r unmodish ]]
  fi
Was testing: -r cond
../../Test/C02cond.ztst: test failed.
../../Test/C03traps.ztst: starting.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: One test suite failure left on static build (after $HOME has been fixed)

[Bart Schaefer]

On Dec 2,  6:20pm, Axel Beckert wrote:
}
} Leaves this test suite error:
} 
} ../../Test/C02cond.ztst: starting.
} Test ../../Test/C02cond.ztst failed: bad status 1, expected 0 from:
}   if (( EUID == 0 )); then
}     print -u$ZTST_fd 'Warning: Not testing [[ ! -r file ]] (root reads anything)'
}     [[ -r zerolength && -r unmodish ]]
}   elif [[ $OSTYPE = cygwin ]]; then
}     print -u$ZTST_fd 'Warning: Not testing [[ ! -r file ]]
}    (all files created by user may be readable)'
}    [[ -r zerolength ]]
}   else
}     [[ -r zerolength && ! -r unmodish ]]
}   fi
} Was testing: -r cond

This could be a umask issue, there's an implicit assumption that

    umask 077
    touch zerolength
    chgrp $EGID zerolength

will create a readable file, and that

    touch unmodish
    chmod 000 unmodish

will create an UNreadable file.  Unfortunately it's not possible to
tell from the test which one of (-r zerolength) or (! -r unmodish)
failed.  I have no idea why running this in the package build would
affect this, though.

Test suite failures in 5.0.2-test-1 _and_ 5.0.2-test-3 on automatic build (was: Re: 5.0.2-test-2 is available)

[Axel Beckert]

Hi,

On Mon, Dec 02, 2013 at 04:15:02PM +0100, Axel Beckert wrote:
> 5.0.2-test-1 btw. had one test-suite failure when building inside a
> jenkins automatic build:
> http://jenkins.grml.org/view/Debian/job/zsh-binaries/90/architecture=i386/console
>
> As soon as I have 5.0.2-test-3 building, I'll check if that still
> happens. Just thought, I should give a heads up as soon as possible
> (since I've already waited to long to do so).

This issue is still there with 5.0.2-test-3:

http://jenkins.grml.org/view/Debian/job/zsh-binaries/architecture=i386/91/console

The following test fails:

[…]
../../Test/A05execution.ztst: starting.
Unable to change MONITOR option
*** /tmp/zsh.ztst.err.16395	Mon Dec  2 16:15:29 2013
--- /tmp/zsh.ztst.terr.16395	Mon Dec  2 16:15:29 2013
***************
*** 0 ****
--- 1 ----
+ (eval):setopt:1: can't change option: MONITOR
Test ../../Test/A05execution.ztst failed: error output differs from expected as shown above for:
  setopt MONITOR
  [[ -o MONITOR ]] || print -u $ZTST_fd 'Unable to change MONITOR option'
  repeat 2048; do (return 2 |
                   return 1 |
                   while true; do
                             false
                             break
                           done;
                   print "${pipestatus[@]}")
		   ZTST_hashmark
  done | sort | uniq -c | sed 's/^ *//'
Was testing: Check whether `$pipestatus[]' behaves.
../../Test/A05execution.ztst: test failed.
The following may (or may not) help identifying the cause:
  This test checks for a bug in `$pipestatus[]' handling.  If it breaks then
  the bug is still there or it reappeared. See workers-29973 for details.
../../Test/A06assign.ztst: starting.
[…]
../../Test/Y03arguments.ztst: all tests successful.
**************************************
41 successful test scripts, 1 failure, 0 skipped
**************************************

That code was last touched recently by the following two commits:

commit c3114a7735c85b79771e08bd156470bde1a36950
Author: Barton E. Schaefer <schaefer@zsh.org>
Date:   Sat Oct 26 16:11:40 2013 -0700

    31906: fix race-condition interaction of $pipestatus with job control
    
    printjob() should not reference oldjobtab for job numbers unless
    it is being called from bin_fg(). printjob() also must not attempt
    to update pipestats when called from bin_fg(). acquire_pgrp()
    should not loop infintely if the shell is not interactive. Update
    the $pipestatus stress test so that it also exercises the
    oldjobtab repair.

commit 65e131c838be6a300b41e3fa8259c281714e4918
Author: Barton E. Schaefer <schaefer@zsh.org>
Date:   Wed Oct 23 22:45:02 2013 -0700

    31879 plus misc.:  improve $pipestatus handling and add a test for it

Since this test does not fail on a normal package build, I suspect
it's related to being connected to a terminal or not.

> > 2. Builtins that are marked to be loaded from modules (using "zmodload")
> > no longer cause an error if the module was already loaded.  This was
> > apparently causing a problem with the previous test version.
> 
> Thanks for that fix. (Not yet verified, but I'm optimistic. :-)

Confirmed, thanks!

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Test suite failures in 5.0.2-test-1 _and_ 5.0.2-test-3 on automatic build (was: Re: 5.0.2-test-2 is available)

[Bart Schaefer]

On Dec 2,  5:28pm, Axel Beckert wrote:
}
} *** /tmp/zsh.ztst.err.16395	Mon Dec  2 16:15:29 2013
} --- /tmp/zsh.ztst.terr.16395	Mon Dec  2 16:15:29 2013
} ***************
} *** 0 ****
} --- 1 ----
} + (eval):setopt:1: can't change option: MONITOR

This is a tough one to reproduce because I can't manually create a case
where the MONITOR option can't be reset.

However, changing the option is non-critical to the test itself, so it's
only necessary to suppress the extra stderr output.

Attempting to test this did reveal that acquire_pgrp() can still be caused
to go into an infinite loop, even after the patch in 31906, if the shell
that is attempting to assert MONITOR is sufficiently far down the process
tree from the parent that actually controls the terminal.  I guess that
loop just needs to give up after a certain number of failed attempts, if
it really needs to be a loop at all.  (No patch for that yet.)

diff --git a/Test/A05execution.ztst b/Test/A05execution.ztst
index ba7e02c..61f6f5a 100644
--- a/Test/A05execution.ztst
+++ b/Test/A05execution.ztst
@@ -179,7 +179,7 @@
 0:Status reset by starting a backgrounded command
 >0
 
-  setopt MONITOR
+  { setopt MONITOR } 2>/dev/null
   [[ -o MONITOR ]] || print -u $ZTST_fd 'Unable to change MONITOR option'
   repeat 2048; do (return 2 |
                    return 1 |

Re: Test suite failures in 5.0.2-test-1 _and_ 5.0.2-test-3 on automatic build (was: Re: 5.0.2-test-2 is available)

[Axel Beckert]

Hi,

On Mon, Dec 02, 2013 at 09:22:15AM -0800, Bart Schaefer wrote:
> On Dec 2,  5:28pm, Axel Beckert wrote:
> }
> } *** /tmp/zsh.ztst.err.16395	Mon Dec  2 16:15:29 2013
> } --- /tmp/zsh.ztst.terr.16395	Mon Dec  2 16:15:29 2013
> } ***************
> } *** 0 ****
> } --- 1 ----
> } + (eval):setopt:1: can't change option: MONITOR
> 
> This is a tough one to reproduce because I can't manually create a case
> where the MONITOR option can't be reset.
> 
> However, changing the option is non-critical to the test itself, so it's
> only necessary to suppress the extra stderr output.
> 
> Attempting to test this did reveal that acquire_pgrp() can still be caused
> to go into an infinite loop, even after the patch in 31906, if the shell
> that is attempting to assert MONITOR is sufficiently far down the process
> tree from the parent that actually controls the terminal.  I guess that
> loop just needs to give up after a certain number of failed attempts, if
> it really needs to be a loop at all.  (No patch for that yet.)
> 
> diff --git a/Test/A05execution.ztst b/Test/A05execution.ztst
> index ba7e02c..61f6f5a 100644
> --- a/Test/A05execution.ztst
> +++ b/Test/A05execution.ztst
> @@ -179,7 +179,7 @@
>  0:Status reset by starting a backgrounded command
>  >0
>  
> -  setopt MONITOR
> +  { setopt MONITOR } 2>/dev/null
>    [[ -o MONITOR ]] || print -u $ZTST_fd 'Unable to change MONITOR option'
>    repeat 2048; do (return 2 |
>                     return 1 |

Still fails, now looks like this:

http://jenkins.grml.org/view/Debian/job/zsh-binaries/92/architecture=i386/console

../../Test/A05execution.ztst: starting.
Unable to change MONITOR option
*** /tmp/zsh.ztst.err.1283	Mon Dec  2 18:04:46 2013
--- /tmp/zsh.ztst.terr.1283	Mon Dec  2 18:04:46 2013
***************
*** 0 ****
--- 1 ----
+ (eval):setopt:1: can't change option: MONITOR
Test ../../Test/A05execution.ztst failed: error output differs from expected as shown above for:
  setopt MONITOR
  externFunc() { awk >/dev/null 2>&1; true; }
  false | true | false | true | externFunc
  echo $pipestatus
Was testing: Check $pipestatus with a known difficult case
../../Test/A05execution.ztst: test failed.
The following may (or may not) help identifying the cause:
  This similar test was triggering a reproducible failure with pipestatus.
../../Test/A06assign.ztst: starting.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Test suite failures in 5.0.2-test-1 _and_ 5.0.2-test-3 on automatic build (was: Re: 5.0.2-test-2 is available)

[Bart Schaefer]

On Dec 2,  7:25pm, Axel Beckert wrote:
} 
} > -  setopt MONITOR
} > +  { setopt MONITOR } 2>/dev/null
} 
} Still fails, now looks like this:

[...]

} + (eval):setopt:1: can't change option: MONITOR
} Test ../../Test/A05execution.ztst failed: error output differs from expected as shown above for:
}   setopt MONITOR


Looks like you didn't actually apply the patch?

-- 
Barton E. Schaefer

Re: Test suite failures in 5.0.2-test-1 _and_ 5.0.2-test-3 on automatic build (was: Re: 5.0.2-test-2 is available)

[Bart Schaefer]

On Dec 2,  7:25pm, Axel Beckert wrote:
}
} Test ../../Test/A05execution.ztst failed: error output differs from expected as shown above for:
}   setopt MONITOR
}   externFunc() { awk >/dev/null 2>&1; true; }

Oops, my mistake -- didn't realize there were two "setopt MONITOR" in
there.

[SOLVED] Re: Test suite failures in 5.0.2-test-1 _and_ 5.0.2-test-3 on automatic build (was: Re: 5.0.2-test-2 is available)

[Axel Beckert]

Hi,

On Mon, Dec 02, 2013 at 10:34:16AM -0800, Bart Schaefer wrote:
> On Dec 2,  7:25pm, Axel Beckert wrote:
> }
> } Test ../../Test/A05execution.ztst failed: error output differs from expected as shown above for:
> }   setopt MONITOR
> }   externFunc() { awk >/dev/null 2>&1; true; }
> 
> Oops, my mistake -- didn't realize there were two "setopt MONITOR" in
> there.

Yay, with patching both occurrences, the package builds fine again.
Thanks for the help!

Full patch so far:

Index: zsh/Test/A05execution.ztst
===================================================================
--- zsh.orig/Test/A05execution.ztst     2013-12-03 08:49:42.000000000 +0100
+++ zsh/Test/A05execution.ztst  2013-12-03 08:49:58.000000000 +0100
@@ -179,7 +179,7 @@
 0:Status reset by starting a backgrounded command
 >0
 
-  setopt MONITOR
+  { setopt MONITOR } 2>/dev/null
   [[ -o MONITOR ]] || print -u $ZTST_fd 'Unable to change MONITOR option'
   repeat 2048; do (return 2 |
                    return 1 |
@@ -195,7 +195,7 @@
 F:This test checks for a bug in `$pipestatus[]' handling.  If it breaks then
 F:the bug is still there or it reappeared. See workers-29973 for details.
 
-  setopt MONITOR
+  { setopt MONITOR } 2>/dev/null
   externFunc() { awk >/dev/null 2>&1; true; }
   false | true | false | true | externFunc
   echo $pipestatus

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: 5.0.2-test-2 is available

[Peter Stephenson]

On Mon, 09 Dec 2013 11:53:18 +0200
İsmail Dönmez <ismail@donmez.ws> wrote:
> >  + ../Util/helpfiles
> >  Usage: helpfiles zshbuiltins.1 dest-dir [link-file]
> 
> Looks like the following rpm spec file fragment triggers this:
> 
>  # make help text files
>  install -d Help
>  pushd Help/
>  troff -Tlatin1 -t -mandoc ../Doc/zshbuiltins.1 | \
>       grotty -cbou | \
>       sed -e 's/±/{+|-}/' | \
>       ../Util/helpfiles
>  popd

(Moved to zsh-workers.)

That probably ought to be "perl ../Util/helpfiles" to be safe.  I think
the code within the distribution does this OK.

pws

Re: 5.0.2-test-2 is available

[İsmail Dönmez]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

Hi,


On Mon, Dec 9, 2013 at 12:12 PM, Peter Stephenson
<p.stephenson@samsung.com>wrote:

> On Mon, 09 Dec 2013 11:53:18 +0200
> İsmail Dönmez <ismail@donmez.ws> wrote:
> > >  + ../Util/helpfiles
> > >  Usage: helpfiles zshbuiltins.1 dest-dir [link-file]
> >
> > Looks like the following rpm spec file fragment triggers this:
> >
> >  # make help text files
> >  install -d Help
> >  pushd Help/
> >  troff -Tlatin1 -t -mandoc ../Doc/zshbuiltins.1 | \
> >       grotty -cbou | \
> >       sed -e 's/±/{+|-}/' | \
> >       ../Util/helpfiles
> >  popd
>
> (Moved to zsh-workers.)
>
> That probably ought to be "perl ../Util/helpfiles" to be safe.  I think
> the code within the distribution does this OK.
>

Looks like this code is not needed at all now. Doc/help/* seems to provide
the help files already. Thanks a lot! Now only remaining test failure is
the MONITOR thing which is already known.

Regards.