Bug#1065041: src:racket-mode: fails to migrate to testing for too long: autopkgtest failure
Source: racket-mode Version: 20231222git0-1 Severity: serious Control: close -1 20240129git0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:racket-mode has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest. By the looks of it, due to progression (but I might be reading the logs wrong): """ 162s Ran 15 tests, 11 results as expected, 1 unexpected, 3 skipped (2024-02-28 18:16:14+, 116.541772 sec) """ If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=racket-mode OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060413: src:emacs-posframe: fails to migrate to testing for too long: uploader built arch:all binary
Source: emacs-posframe Version: 1.1.7-3 Severity: serious Control: close -1 1.4.2-1 Tags: sid trixie pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:emacs-posframe has been trying to migrate for 33 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=emacs-posframe OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060412: src:emacs-wgrep: fails to migrate to testing for too long: autopkgtest regression
Source: emacs-wgrep Version: 3.0.0-1 Severity: serious Control: close -1 3.0.0-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:emacs-wgrep has been trying to migrate for 33 days [2]. Hence, I am filing this bug. The version in unstable fails its own autopkgtest. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=emacs-wgrep OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1053494: src:hl-todo-el: fails to migrate to testing for too long: not installable
Source: hl-todo-el Version: 3.5.0-1 Severity: serious Control: close -1 3.6.0-1 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:hl-todo-el has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable can't be installed, elpa-compat is still at 29.1.4.1-2. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=hl-todo-el OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1033852: racket-mode: autopkgtest regression: Process *Racket REPL* connection broken by remote peer
Source: racket-mode
Version: 20210916git0-2
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
Your package has an autopkgtest, great. However, it fails since December
2022 in testing. Can you please investigate the situation and fix it? I
copied some of the output at the bottom of this report.
The release team has announced [1] that failing autopkgtest on amd64 and
arm64 are considered RC in testing. [Release Team member hat on] Because
we're currently in the hard freeze for bookworm, I have marked this bug
as bookworm-ignore. Targeted fixes are still welcome.
More information about this bug and the reason for filing it can be
found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
https://ci.debian.net/data/autopkgtest/testing/amd64/r/racket-mode/32133920/log.gz
racket-tests/repl
Indenting region...
Indenting region...done
Indenting region...
Indenting region...done
Indenting region...
Indenting region...done
Indenting region...
Indenting region...done
Indenting region...
Indenting region...done
Test racket-tests/repl backtrace:
signal(ert-test-failed (((should (racket-tests/see-back expected)) :
ert-fail(((should (racket-tests/see-back expected)) :form (racket-te
(if (unwind-protect (setq value-37 (apply fn-35 args-36)) (setq form
(let (form-description-39) (if (unwind-protect (setq value-37 (apply
(let ((value-37 'ert-form-evaluation-aborted-38)) (let (form-descrip
(let* ((fn-35 #'racket-tests/see-back) (args-36 (condition-case err
(closure ((expected . "(cond [(values 1) #t] [else #f])\n#t\n> ") (t
mapc((closure ((expected . "(cond [(values 1) #t] [else #f])\n#t\n>
(let ((typing "[cond [[values 1] #t] [else #f]]") (expected "(cond [
(closure (t) nil (let* ((fn-0 #'racket-tests/see-back-rx) (args-1 (c
racket--call-with-repl-buffer((closure (t) nil (let* ((fn-0 #'racket
(closure (t) nil (racket-repl) (racket-tests/call-until-true #'(lamb
funcall((closure (t) nil (racket-repl) (racket-tests/call-until-true
(unwind-protect (funcall thunk) (racket-stop-back-end))
(let ((racket-command-timeout racket-tests/timeout)) (unwind-protect
racket-tests/call-with-back-end-settings((closure (t) nil (racket-re
(let ((lexical-binding t)) (message "racket-tests/repl") (racket-tes
(closure (t) nil (let ((lexical-binding t)) (message "racket-tests/r
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name racket-tests/repl :documentation "Sta
ert-run-or-rerun-test(#s(ert--stats :selector t :tests ... :test-map
ert-run-tests(t #f(compiled-function (event-type event-args) #
ert-run-tests-batch(nil)
ert-run-tests-batch-and-exit()
command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
command-line()
normal-top-level()
Test racket-tests/repl condition:
(ert-test-failed
((should
(racket-tests/see-back expected))
:form
(racket-tests/see-back "(cond [(values 1) #t] [else #f])\n#t\n> ")
:value nil :explanation
(actual . "; \n; Welcome to Racket v8.7 [cs].\n; \n>
current-output-port\n#\n> (if 1\n
2\n 3)\n2\n> (cond [(values 1) #t] [else #f])\n#t\n> (cond [(values
1) #t] [else #f])\n#t\n> (cond [(values 1) #t] [else #f])\n")))
FAILED 10/12 racket-tests/repl (15.518214 sec)
racket-tests/run
run: current-repl-msg-chan was #f; current-session-id=#f
Test racket-tests/run backtrace:
signal(ert-test-failed (((should (racket-tests/see-back (concat "\n"
ert-fail(((should (racket-tests/see-back (concat "\n" name "> "))) :
(if (unwind-protect (setq value-72 (apply fn-70 args-71)) (setq form
(let (form-description-74) (if (unwind-protect (setq value-72 (apply
(let ((value-72 'ert-form-evaluation-aborted-73)) (let (form-descrip
(let* ((fn-70 #'racket-tests/see-back) (args-71 (condition-case err
(closure ((code . "#lang racket/base\n(define foobar 42)\nfoobar\n")
racket--call-with-repl-buffer((closure ((code . "#lang racket/base\n
(let* ((path (make-temp-file "test" nil ".rkt")) (name (file-name-no
(closure (t) nil (let* ((path (make-temp-file "test" nil ".rkt")) (n
funcall((closure (t) nil (let* ((path (make-temp-file "test" nil ".r
(unwind-protect (funcall thunk) (racket-stop-back-end))
(let ((racket-command-timeout racket-tests/timeout)) (unwind-protect
racket-tests/call-with-back-end-settings((closure (t) nil (let* ((pa
(let ((lexical-binding t)) (message "racket-tests/run") (racket-test
(closure (t) nil (let ((lexical-binding t)) (message "racket-tests/r
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name racket-tests/run :documentation "Star
ert-run-or-rerun-test(#s(ert--stats :selector t :tests ... :test-map
ert-run-tests(t #f(compiled-function (event-type event-args) #
Bug#1033697: flycheck: autopkgtest fails: trampoline file does not exists
Source: flycheck
Version: 32~git.20200527.9c435db3-3
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
Your package has an autopkgtest, great. However, it fails since January
2023. Can you please investigate the situation and fix it? I copied some
of the output at the bottom of this report.
The release team has announced [1] that failing autopkgtest on amd64 and
arm64 are considered RC in testing.
More information about this bug and the reason for filing it can be
found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
https://ci.debian.net/data/autopkgtest/testing/amd64/f/flycheck/32470842/log.gz
[31mUtilities flycheck-buffer-saved-p considers an unmodified buffer
with backing file saved[0m
Traceback (most recent call last):
spy-on(buffer-file-name :and-return-value "test-buffer-name")
buttercup--spy-on-and-call-replacement(buffer-file-name (lambda
( arg...
comp-subr-trampoline-install(buffer-file-name)
comp-trampoline-search(buffer-file-name)
native-elisp-load("/home/debci/.emacs.d/eln-cache/28.2-ffd0c654/subr--tram...
error: (native-lisp-load-failed "file does not exists"
"/home/debci/.emacs.d/eln-cache/28.2-ffd0c654/subr--trampoline-627565722d66696c652d6e616d65_buffer_file_name_0.eln")
[31mUtilities flycheck-buffer-saved-p considers a modified buffer with
backing file unsaved[0m
Traceback (most recent call last):
spy-on(buffer-file-name :and-return-value "test-buffer-name")
buttercup--spy-on-and-call-replacement(buffer-file-name (lambda
( arg...
comp-subr-trampoline-install(buffer-file-name)
comp-trampoline-search(buffer-file-name)
native-elisp-load("/home/debci/.emacs.d/eln-cache/28.2-ffd0c654/subr--tram...
error: (native-lisp-load-failed "file does not exists"
"/home/debci/.emacs.d/eln-cache/28.2-ffd0c654/subr--trampoline-627565722d66696c652d6e616d65_buffer_file_name_0.eln")
Ran 109 out of 110 specs, 2 failed, in 389.98ms.
OpenPGP_signature
Description: OpenPGP digital signature
Re: Bug#1023297: src:emacs: fails to migrate to testing for too long: unresolved RC issues
Hi Sean, On 09-12-2022 18:56, Sean Whitton wrote: If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Alright, all the RC bugs are closed. Of the four autopkgtest failures, emacs-deferred and flycheck we need to wait and see when they are re-run, Which happens daily. But I guess gcc needs to migrate first for the retest to be useful? I triggered some tests already in unstable and flycheck failed [1, 2]. emacs-defered seems to be fixed in unstable. but the evil-el and haskell-mode failures are due to bugs in those packages. evil-el is orphaned and haskell-mode is unmaintained. Could they both be hinted out of testing, please? I've added removal hints, I might need an iteration more. Paul [1] https://ci.debian.net/data/autopkgtest/unstable/amd64/f/flycheck/29209094/log.gz [2] https://ci.debian.net/data/autopkgtest/unstable/arm64/f/flycheck/29209095/log.gz OpenPGP_signature Description: OpenPGP digital signature
Bug#1023225: esup-el: autopkgtest regression: No such file or directory, comp
Source: esup-el Version: 0.7.1-4 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of esup-el the autopkgtest of esup-el fails in testing when that autopkgtest is run with the binary packages of esup-el from unstable. It passes when run with only packages from testing. In tabular form: passfail esup-elfrom testing0.7.1-4 all others from testingfrom testing I copied some of the output at the bottom of this report. I'm seeing command lines about native complilation. Are you sure you don't need a new enough emacs that supports that for your test or package? Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=esup-el https://ci.debian.net/data/autopkgtest/testing/amd64/e/esup-el/27685397/log.gz emacs -batch -Q -l package --eval "(setq native-comp-eln-load-path '(\"/tmp/3oIzPMCFGJ\"))" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -L test -l test/esup-test.el --eval \(ert-run-tests-batch-and-exit\) Cannot open load file: No such file or directory, comp dh_elpa_test: error: emacs -batch -Q -l package --eval "(setq native-comp-eln-load-path '(\"/tmp/3oIzPMCFGJ\"))" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -L test -l test/esup-test.el --eval \(ert-run-tests-batch-and-exit\) returned exit code 255 autopkgtest [23:12:43]: test dh-elpa-test-autopkgtest OpenPGP_signature Description: OpenPGP digital signature
Bug#996719: "Provides: elpa-dash-functional" needs to be versioned to satify elpa-helpful
Package: elpa-dash Version: 2.19.0+dfsg-1 Severity: important Dear maintainers, With the upload of 2.19.0+dfsg-1 elpa-dash took over elpa-dash-functional via a Provides. However, elpa-helpful has a versioned dependency on elpa-dash-functional. Policy 7.5 says this: """ If the Provides field does not specify a version number, it will not satisfy versioned dependencies or violate versioned Conflicts or Breaks. """ Please add a version to the Provides, otherwise elpa-dash can't take over elpa-dash-functional in testing [1]. Paul [1] https://release.debian.org/britney/update_output.txt -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-dash depends on: ii dh-elpa-helper 2.0.9 ii emacsen-common 3.0.4 elpa-dash recommends no packages. elpa-dash suggests no packages.
Bug#990818: rtags: flaky autopkgtest: regularly times out after 2:47 h
Source: rtags Version: 2.38-3 Severity: serious Tags: bulleye-ignore X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: flaky timeout Dear maintainer(s), Your package has an autopkgtest, great. However, due to glibc reporting a regression, I looked into the history of your autopkgtest [1] and I noticed it fails regularly on ppc64el (and I spotted a similar failure on i386). I copied some of the output at the bottom of this report. It hits the autopkgtest time out after 2hours and 47 minutes. Successful runs pass in a couple of minutes. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul [Release team member hat on: as we are so late in the freeze, I don't want this bug to kick your package out of bulleye. Hence, the bulleye-ignore tag.] [1] https://ci.debian.net/packages/r/rtags/testing/ppc64el/ https://ci.debian.net/data/autopkgtest/testing/ppc64el/r/rtags/13432732/log.gz autopkgtest [01:18:38]: test run-test: [--- = test session starts == platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0 -- /usr/bin/python3 cachedir: .pytest_cache rootdir: /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/build.A6f/src collecting ... collected 14 items tests/automated/test_misc.py::test_location[InlineConstructorWrongTarget] PASSED tests/automated/test_misc.py::test_location[ClassTemplatesMultipleTU] PASSED tests/automated/test_misc.py::test_location[OneTU] PASSED tests/automated/test_misc.py::test_location[ClassTemplates] PASSED tests/automated/test_misc.py::test_location[MetaPrograms] PASSED tests/automated/test_misc.py::test_location[ForwardDeclaration] PASSED tests/automated/test_misc.py::test_location[AnonymousUnion] PASSED tests/automated/test_misc.py::test_location[FunctionTemplates] PASSED tests/automated/test_misc.py::test_location[MultipleTU] PASSED tests/automated/test_misc.py::test_location[FunctionPointerField] PASSED tests/automated/test_misc.py::test_parse[Parsing] PASSED tests/automated/test_misc.py::test_completion[Completion] PASSED tests/automated/test_misc.py::test_output[PrintIncludePathOutput] autopkgtest [04:05:18]: ERROR: timed out on command "su -s /bin/bash debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; . ~/.profile >/dev/null 2>&1 || true; buildtree="/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/build.A6f/src"; mkdir -p -m 1777 -- "/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-artifacts"; export AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-artifacts"; export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 "/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/autopkgtest_tmp"; export AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.5r1qzd3h/downtmp/autopkgtest_tmp"; export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod +x /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/build.A6f/src/debian/tests/run-test; touch /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-stdout /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-stderr; /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/build.A6f/src/debian/tests/run-test 2> >(tee -a /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-stderr >&2) > >(tee -a /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/run-test-stdout);" (kind: test) autopkgtest [04:05:19]: test run-test: ---] OpenPGP_signature Description: OpenPGP digital signature
Bug#975581: src:org-mode-doc: fails to migrate to testing for too long: non-free source package not autobuild
Source: org-mode-doc Version: 9.3-1 Severity: serious Control: close -1 9.4.0-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), You uploaded the latest version of org-mod-doc as a source only. That's the required way for the main archive, however, non-free packages aren't automatically autobuild. You'll have to get it added to the list: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-free-buildd or upload the binaries yourself. As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:org-mode-doc in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=org-mode-doc signature.asc Description: OpenPGP digital signature
Bug#975093: weechat-el: autopkgtest regression: Eager macro-expansion failure: (error "Unknown rx form ‘std’")
Source: weechat-el Version: 0.5.0-4 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of weechat-el the autopkgtest of weechat-el fails in testing when that autopkgtest is run with the binary packages of weechat-el from unstable. It passes when run with only packages from testing. In tabular form: passfail weechat-el from testing0.5.0-4 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=weechat-el https://ci.debian.net/data/autopkgtest/testing/amd64/w/weechat-el/8248534/log.gz Install emacsen-common for emacs emacsen-common: Handling install of emacsen flavor emacs Install elpa-weechat for emacs install/weechat-0.5.0: Handling install of emacsen flavor emacs install/weechat-0.5.0: byte-compiling for emacs Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-button.el:32:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-cmd.el:40:1:Error: Symbol’s function definition is void: rx-let In toplevel form: weechat-color.el:76:1:Error: Unknown rx form ‘std’ Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-complete.el:36:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-corrector.el:33:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-image.el:32:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-latex.el:31:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-notifications.el:31:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-read-marker.el:34:1:Error: Symbol’s function definition is void: rx-let In weechat--unpack-message-contents: weechat-relay.el:383:53:Warning: ‘string-make-unibyte’ is an obsolete function (as of 26.1); use ‘encode-coding-string’. In weechat--relay-process-filter: weechat-relay.el:489:16:Warning: ‘string-make-unibyte’ is an obsolete function (as of 26.1); use ‘encode-coding-string’. Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-sauron.el:31:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-secrets.el:36:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-smiley.el:57:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-speedbar.el:30:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-spelling.el:29:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-test.el:1:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat-tracking.el:37:1:Error: Symbol’s function definition is void: rx-let Eager macro-expansion failure: (error "Unknown rx form ‘std’") In toplevel form: weechat.el:36:1:Error: Symbol’s function definition is void: rx-let ERROR: install script from elpa-weechat package failed dpkg: error processing package emacs-nox (--configure): installed emacs-nox package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of dh-elpa: dh-elpa depends on emacs-nox (>= 47) | emacs (>= 47.0); however: Package emacs-nox is not configured yet. Package emacs is not installed. Version of emacs on system, provided by emacs-nox:amd64, is . dpkg: error processing package dh-elpa (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of autopkgtest-satdep: autopkgtest-satdep depends on dh-elpa (>= 1.7); however: Package dh-elpa is not configured yet. dpkg: error processing package autopkgtest-satdep (--configure): dependency
Bug#954368: src:haskell-mode: fails to migrate to testing for too long
Source: haskell-mode Version: 16.1-8 Severity: serious Control: fixed -1 17.1-2 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:haskell-mode in its current version in unstable has been trying to migrate for 61 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have marked the version in unstable as fixing this bug, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=haskell-mode signature.asc Description: OpenPGP digital signature
