[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#910897: marked as done (elpy: reenable elpy-promise-wait-should-return-early-for-resolved-promise)

Your message dated Mon, 28 Jan 2019 02:32:18 -0700
with message-id <20190128093215.x5oqaqvvf2ang5my@navis>
and subject line Re: elpy: reenable elpy-promise-wait-should-return-early-for-resolved-promise
has caused the Debian Bug report #910897,
regarding elpy: reenable elpy-promise-wait-should-return-early-for-resolved-promise
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
910897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910897
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Source: elpy
Version: 1.24.0-1
Severity: serious
Tags: ftbfs

elpy fails to build from source randomly. A build log contains:

| 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. 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.

Helmut

--- End Message ---
--- Begin Message --- 
Control: fixed -1 1.28.0-1

Hi Helmut,

I re-enabled the test after the python-3.7 migration, following my
hypothesis that it's a Python 3.6.7rc1-specific bug.  Looks like it's
good again:
  https://ci.debian.net/packages/e/elpy/unstable/amd64/

I forwarded the bug some time ago, and if upstream cannot reproduce it
when they add Python 3.7 to their CI (they already have 3.6), then I
expect the forwarded bug will be closed.  Closing this one now,
because the transition freeze has passed and I believe Elpy promises
are good for Buster.

Thanks again for notifying me of the failing test!
Regards,
Nicholas

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: