Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: zpty-related testsuite failures if building in a chroot on a host running systemd 220 as init system



Hi,

On Sat, Jun 13, 2015 at 06:01:54PM +0100, Peter Stephenson wrote:
> On Sat, 13 Jun 2015 12:48:58 +0200
> Axel Beckert <abe@xxxxxxxxxxxxxxx> wrote:
> > The only thing which is IMHO left on the zsh side is why the testsuite
> > fails (instead of e.g. skipping the according tests) if /dev/pts/ptmx
> > is missing. Is this on purpose? Or just never occurred before? (Mostly
> > curious. :-)
> 
> Sounds like you've got to the bottom of this, which is good.

Yes, I'm glad, too. Especially because afterwards I could upload zsh
5.0.8 to Debian Unstable with good conscience. :-)

It so far build fine on all architectures except GNU Hurd:
https://buildd.debian.org/status/package.php?p=zsh

5.0.8 on sparc hasn't been built yet and the build failure on GNU Hurd
seems to have been an endless loop in the configure script which means
that the issue is rather in autotools than in zsh.

On Sat, Jun 13, 2015 at 10:43:33AM -0700, Bart Schaefer wrote:
> On Jun 13,  6:01pm, Peter Stephenson wrote:
> }
> } I guess it would be possible to have a "broken posxix_openpt" test ---
> 
> Not at configure time -- that would result in the module being left
> uncompiled, when in fact outside of the chroot it would work.

Yeah, I'd say the test suite should not expect to be run in the same
environment as the build. E.g. in Debian we run it directly after the
build inside the build environment, but also "as installed"
afterwards: http://ci.debian.net/packages/z/zsh/unstable/amd64/ (5.0.8
is still missing there, as there may occur lags up to a few days.)

> I think the test failing here was exactly the right thing, as it led to
> the origin of the problem being discovered.

Yes and no. I'm glad about it failing, yes.

> The only viable alternative would be to report the test as "skipped"

That's what I imagined.

> which I guess would be OK for the secondary tests that rely on zpty,
> but not for V08zpty itself.

Hrm. If I know, I the zpty tests would fail due to the environment,
I'd tend to skip them as I would skip 64-bit-only tests in a 32-bit
environment.

> I suppose the test suite could remember that V08 failed and therefore
> skip X02 and all of Y, so as to isolate the problem better.  We could
> add some sort of dependency check.

Actually I think that's overkill. It was clear for me in this case
that all failing tests were zpty related.

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



Messages sorted by: Reverse Date, Date, Thread, Author