GNU bug report logs - #36940
tests slowness and failure after recent Tramp changes

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Tue, 6 Aug 2019 00:29:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 36940 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 36940 <at> debbugs.gnu.org
Subject: Re: bug#36940: tests slowness and failure after recent Tramp changes
Date: Tue, 06 Aug 2019 14:59:17 +0200
Paul Eggert <eggert <at> cs.ucla.edu> writes:

Hi Paul,

> I'm having trouble with 'make check' after the recent Tramp changes on
> master. First, the Tramp tests are now too slow; they take over 6
> minutes on my platform (Fedora 30 x86-4, AMD Phenom II X4 910e,
> default optimization), which is so slow that I don't want to run 'make
> check' while developing, which would be a bad habit to get into.

You have run the expensive tests with this call. If you want to run the
default tests, which are active while "make check", you must use the
default selector. See test/README. On my local machine, this makes the
following difference:

$ make tramp-tests
Ran 67 tests, 65 results as expected, 1 unexpected, 1 skipped (2019-08-06 14:45:25+0200, 420.067490 sec)

$ make tramp-tests SELECTOR='$(SELECTOR_DEFAULT)'
Ran 47 tests, 45 results as expected, 1 unexpected, 1 skipped (2019-08-06 14:49:12+0200, 29.771561 sec)

Note, that you don't need the whole path of the test file, its basename
is sufficient.

> Second, the tramp-test19-directory-files-and-attributes test now fails.

Hmm, prior pushing the patch yesterday, all tests have passed. Today, I
can reproduce the problem. Maybe some of the time conversion changes,
arrived over night, have caused this failure? Will check.

> A nit: the output has some weird spacing and log lines.

I know. Its a continued hunt for years to remove these quirks. Some of
them (like the empty lines) are mysterious, and hard to detect where they
come from.

Best regards, Michael.




This bug report was last modified 5 years and 325 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.