Control: forwarded -1 https://github.com/jorgenschaefer/elpy/issues/1477
Hi Helmut,
On Thu, Oct 04, 2018 at 07:34:31PM +0200, Helmut Grohne wrote:
> Source: elpy
> Version: 1.24.0-1
> Severity: serious
> Tags: ftbfs
>
> elpy fails to build from source randomly. A build log contains:
I'm aware of this and opened an upstream issue a few days ago;
however, I haven't been able to reproduce it locally. I've run more
than 15 autopkgtest runs in my amd64 schroot and another 15 in my LXC
one (not including runs to just build the package). I also can't
trigger it with a plain dpkg-buildpackage.
> | Test elpy-promise-wait-should-return-early-for-resolved-promise backtrace:
> | (if (unwind-protect (setq value-774 (apply fn-772 args-773)) (setq f
> | (let (form-description-776) (if (unwind-protect (setq value-774 (app
> | (let ((value-774 (quote ert-form-evaluation-aborted-775))) (let (for
> | (let ((fn-772 (function elpy-promise-resolved-p)) (args-773 (list pr
> | (let ((start-time (current-time)) (promise (elpy-promise nil))) (run
> | (progn (let ((start-time (current-time)) (promise (elpy-promise nil)
> | (progn (setq elpy-rpc-timeout 100) (progn (let ((start-time (current
> | (unwind-protect (progn (setq elpy-rpc-timeout 100) (progn (let ((sta
> | (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
> | (let ((temp-buffer (generate-new-buffer " *temp*"))) (save-current-b
> | (progn (let ((temp-buffer (generate-new-buffer " *temp*"))) (save-cu
> | (unwind-protect (progn (let ((temp-buffer (generate-new-buffer " *te
> | (let ((old-process-list (process-list)) (old-buffer-list (buffer-lis
> | (lambda nil (let ((old-process-list (process-list)) (old-buffer-list
> | ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
> | ert-run-test([cl-struct-ert-test elpy-promise-wait-should-return-ear
> | ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test e
> | ert-run-tests(t #[385 "\306^B\307\"\203G^@\211\211G\310U\203^T^@\211@\20
> | ert-run-tests-batch(nil)
> | ert-run-tests-batch-and-exit()
> | eval((ert-run-tests-batch-and-exit))
> | command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
> | command-line()
> | normal-top-level()
> | Test elpy-promise-wait-should-return-early-for-resolved-promise condition:
> | (ert-test-failed
> | ((should
> | (elpy-promise-resolved-p promise))
> | :form
> | (elpy-promise-resolved-p
> | [*elpy-promise* nil nil #<killed buffer> nil])
> | :value nil))
> | FAILED 222/362
> elpy-promise-wait-should-return-early-for-resolved-promise
>
> This happened in sbuild on unstable/amd64.
>
> The reproducible builds folks encountered the same failure in one out of
> two builds using pbuilder:
>
> https://tests.reproducible-builds.org/debian/logs/unstable/amd64/elpy_1.24.0-1.build2.log.gz
> https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/elpy_1.24.0-1.rbuild.log.gz
> https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/elpy_1.24.0-1.rbuild.log.gz
>
> For amd64, only the second build failed.
Other than the build1 to build2 diff, where can I find a list of
everything that varies between the two runs? At this time my best
guesses are a UTF-8 issue (possibly related to python-3.7), behaviour
that changed between python-3.6 and python-3.7, the mysterious cl vs
cl-lib issue that only affects packages built in an LXC (see below
[2]). The only reason I suspect something UTF-8 related is there was
an Elpy bug involving the "ö" character sometime in the last year, and
I noticed that build2 has « guillemets ».
> When I tried it locally in
> sbuild, three builds succeeded. I have no clue how the failure is
> caused, but it is evident that it is not broken infrastructure.
I'm not interested in a blame shifting game, because it's not yet
evident where the issue is. eg: 1) Various emacs tests in other
packages will[have] fail[ed] in pbuilder or in LXC autopkgtest but
always pass in schroot. 2) Autopkgtests began to fail for various
Emacs packages after unversioned emacs was released, but only in LXC,
and no one knows why. I discovered this hack, which doesn't feel
right: Add "ert_eval = (require 'cl)" to debian/elpa-tests. It
doesn't feel right because cl-lib should be used. Of course, it's
also possible that these upstreams have a dynamic (works with cl fails
with cl-lib ) vs lexical scope bug. That said, I'm doing everything I
can to figure this out ;-)
Because you're able to reproduce it, would you please get a debug
shell and run the ERT tests interactively to get an untruncated
backtrace? I'd be happy to help out with this if necessary. If it's
the [2] class of issues then it will only trigger in batch mode and
never in interactive. That said, the [2] class of issues is usually
reliably triggered on any LXC build or autopkgtest run, but it would
be valuable to eliminate this failure case.
Worst-case scenario will be to disable the
`elpy-promise-wait-should-return-early-for-resolved-promise` test.
Cheers,
Nicholas
signature.asc
Description: PGP signature
