Debian testing autoremoval watch <noreply@release.debian.org> writes:
emacs-wgrep 3.0.0-1 is marked for autoremoval from testing on 2024-01-18
It is affected by these RC bugs:
1057559: emacs-wgrep: FTBFS: Error: error ("Test âwgrep-normalâ redefined")
https://bugs.debian.org/1057559
This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
FYI I have prepared a fix on mentors[1]. Comments and sponsors welcome!
[1] https://mentors.debian.net/package/emacs-wgrep/
Jeremy Sowden <jeremy@azazel.net> writes:
On 2024-01-03, at 22:08:32 -0800, Xiyue Deng wrote:
Debian testing autoremoval watch <noreply@release.debian.org> writes:
emacs-wgrep 3.0.0-1 is marked for autoremoval from testing on 2024-01-18 >> >
It is affected by these RC bugs:
1057559: emacs-wgrep: FTBFS: Error: error ("Test âwgrep-normalâ redefined")
https://bugs.debian.org/1057559
This mail is generated by:
https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
Autoremoval data is generated by:
https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
FYI I have prepared a fix on mentors[1]. Comments and sponsors welcome! >>
[1] https://mentors.debian.net/package/emacs-wgrep/
I tried building the package with gbp-buildpackage in Sid and two of the tests failed. The same things happened when I manually ran:
fakeroot debian/rules binary
in a Sid chroot. It is the two BOM tests that fail. For example:
$ schroot -c sid -- emacs -batch -l wgrep.el -l wgrep-test-helper.el -l wgrep-test.el -eval '(ert-run-tests-batch-and-exit "wgrep-bom-with-unibyte")'
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Running 1 tests (2024-01-06 19:35:50+0000, selector `"wgrep-bom-with-unibyte"')
Grep finished with matches found
Press C-x C-s when finished or C-c C-k to abort changes.
Writing 1 files, 0 files are left...
There is an unapplied change. (0 changed)
No buffer has been saved.
Test wgrep-bom-with-unibyte backtrace:
ert-fail(((should (equal "ABCD\nb\n" (wgrep-test-helper--get-content
(if (unwind-protect (setq value-75 (apply fn-73 args-74)) (setq form
(let (form-description-77) (if (unwind-protect (setq value-75 (apply
(let ((value-75 'ert-form-evaluation-aborted-76)) (let (form-descrip
(let* ((fn-73 #'equal) (args-74 (condition-case err (let ((signal-ho
(lambda (file) (wgrep-test-helper--grep (concat "grep -nH -e 'a' -A
funcall((lambda (file) (wgrep-test-helper--grep (concat "grep -nH -e
(unwind-protect (funcall body-fn file) (wgrep-test-helper--cleanup-f
(let ((file (concat (make-temp-name "test-data") ".txt"))) (cond ((s
(let ((default-directory (file-name-as-directory test-directory))) (
(let ((test-directory (expand-file-name "test-work" default-director
wgrep-test-helper-fixture(("a\nb\n" utf-8-with-signature) (lambda (f
(progn (wgrep-test-helper-fixture '("a\nb\n" utf-8-with-signature) #
(let ((wgrep-change-readonly-file nil) (wgrep-auto-save-buffer nil))
(lambda nil (let ((wgrep-change-readonly-file nil) (wgrep-auto-save-
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name wgrep-bom-with-unibyte :documentation
ert-run-or-rerun-test(#s(ert--stats :selector "wgrep-bom-with-unibyt
ert-run-tests("wgrep-bom-with-unibyte" #f(compiled-function (event-t
ert-run-tests-batch("wgrep-bom-with-unibyte")
ert-run-tests-batch-and-exit("wgrep-bom-with-unibyte")
command-line-1(("-l" "wgrep.el" "-l" "wgrep-test-helper.el" "-l" "wg
command-line()
normal-top-level()
Test wgrep-bom-with-unibyte condition:
(ert-test-failed
((should
(equal "ABCD\nb\n"
(wgrep-test-helper--get-contents file)))
:form
(equal "ABCD\nb\n" "a\nb\n")
:value nil :explanation
(arrays-of-different-length 7 4 "ABCD\nb\n" "a\nb\n" first-mismatch-at 0)))
FAILED 1/1 wgrep-bom-with-unibyte (0.743585 sec) at wgrep-test.el:77
Ran 1 tests, 0 results as expected, 1 unexpected (2024-01-06 19:35:51+0000, 0.908359 sec)
1 unexpected results:
FAILED wgrep-bom-with-unibyte
Changing the test to remove the BOM:
--- a/wgrep-test.el
+++ b/wgrep-test.el
@@ -77,7 +77,7 @@
(ert-deftest wgrep-bom-with-unibyte ()
:tags '(wgrep)
(wgrep-test-helper--default
- (wgrep-test-helper-fixture '("a\nb\n" utf-8-with-signature)
+ (wgrep-test-helper-fixture '("a\nb\n" utf-8)
(lambda (file)
(wgrep-test-helper--grep (concat "grep -nH -e 'a' -A 2 " file))
(wgrep-change-to-wgrep-mode)
causes it to pass.
I am trying to work out what's going wrong, but I suspect that your
Elisp skills (and familiarity with the package) are greater than mine
and you may get there faster. :)
Thanks for the report. However, I cannot reproduce this with my
sbuild or sid docker environment. Also as the test is about BOM I
don't think disabling BOM is the right solution.
Can you show me a bit more of your system and package info (with dependencies)?
Jeremy Sowden <jeremy@azazel.net> writes:[snip]
The tests were failing when I ran either:
[snip]Eventually, I tracked the problem down to
locale settings in the environment. In the schroot chroot, `LANG` is
not set; in the cowbuilder chroot it is set to `C`; whereas in the
sbuild chroot, which inherits it from my environment in the host system,
it is `en_GB.UTF-8`.
Not sure what the moral of this tale is yet, but in any case, the
problem is unrelated to your packaging (and I see the same behaviour
using the .orig tar-ball).
Thanks very much for tracking this down!
I have reproduced this in a newly created cowbuilder (in fact both
multibyte and unibyte tests failed), and tested that setting LC_ALL to C.UTF-8 indeed fixes this issue.
Xiyue Deng <manphiz@gmail.com> writes:
Jeremy Sowden <jeremy@azazel.net> writes:[snip]
The tests were failing when I ran either:
[snip]Eventually, I tracked the problem down to
locale settings in the environment. In the schroot chroot, `LANG` is
not set; in the cowbuilder chroot it is set to `C`; whereas in the
sbuild chroot, which inherits it from my environment in the host system, >> it is `en_GB.UTF-8`.
Not sure what the moral of this tale is yet, but in any case, the
problem is unrelated to your packaging (and I see the same behaviour
using the .orig tar-ball).
Jeremy, thank you reviewing this sponsorship request.
Thanks very much for tracking this down!
Yes, thank you. This confirms the hypothesis for part of the (old, from 2020) bug reported upstream here:
https://github.com/mhayashi1120/Emacs-wgrep/issues/78
I have reproduced this in a newly created cowbuilder (in fact both multibyte and unibyte tests failed), and tested that setting LC_ALL to C.UTF-8 indeed fixes this issue.
This action is only correct if all users will use UTF-8 100% of the time because otherwise it sweeps a corner-case under the rug. In other
words, NACK at this time.
Providing correct functioning to users of non-UTF-8 appears to require
this:
https://www.gnu.org/software/emacs/manual/html_node/elisp/Converting-Representations.html
and alternatively, the mode should throw an error on non-UTF-8
systems.
As the package maintainer, I'm willing to sponsor at commit:fc1fac7 or equivalent.
Nicholas D Steeves <sten@debian.org> writes:
Xiyue Deng <manphiz@gmail.com> writes:
This action is only correct if all users will use UTF-8 100% of the time
because otherwise it sweeps a corner-case under the rug. In other
words, NACK at this time.
Providing correct functioning to users of non-UTF-8 appears to require
this:
https://www.gnu.org/software/emacs/manual/html_node/elisp/Converting-Representations.html
and alternatively, the mode should throw an error on non-UTF-8 systems.
c65b0989 was an attempt to avoid failure on buildd in case it doesn't
have the proper locale settings. As I cannot reproduce this issue using sbuild which I think the buildds use, and the previous 3.0.0-2 upload
doesn't fail either, it's probably OK to leave this unresolved for now.
As the package maintainer, I'm willing to sponsor at commit:fc1fac7 or
equivalent.
I can revert to 01379469 which is just before I tried Jeremy's solution
if you are OK to sponsor this.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 68:03:03 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,275,268 |