• emacs-wgrep is marked for autoremoval from testing

    From Debian testing autoremoval watch@21:1/5 to All on Wed Oct 27 07:00:01 2021
    emacs-wgrep 2.3.2+9.gf0ef9bf-2 is marked for autoremoval from testing on 2021-12-01

    It (build-)depends on packages with these RC bugs:
    996795: elpa-ag: silversearcher-ag-el: should drop dependencies on elpa-dash-functional
    https://bugs.debian.org/996795



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian testing autoremoval watch@21:1/5 to All on Thu May 26 08:40:01 2022
    emacs-wgrep 2.3.2+9.gf0ef9bf-2 is marked for autoremoval from testing on 2022-06-30

    It (build-)depends on packages with these RC bugs:
    1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, CVE-2022-28183, CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, CVE-2022-28192
    https://bugs.debian.org/1011146



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian testing autoremoval watch@21:1/5 to All on Tue Sep 27 07:20:02 2022
    emacs-wgrep 2.3.2+9.gf0ef9bf-2 is marked for autoremoval from testing on 2022-11-01

    It (build-)depends on packages with these RC bugs:
    1020190: shut-up: FTBFS: make: *** [debian/rules:4: build] Error 25
    https://bugs.debian.org/1020190
    1020202: undercover-el: FTBFS: (file-missing "Opening input file" "No such file or directory" "/tmp/first-example-library-report.json")
    https://bugs.debian.org/1020202



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian testing autoremoval watch@21:1/5 to All on Sat Jul 1 07:30:01 2023
    emacs-wgrep 3.0.0-1 is marked for autoremoval from testing on 2023-07-30

    It (build-)depends on packages with these RC bugs:
    999962: silversearcher-ag: depends on obsolete pcre3 library
    https://bugs.debian.org/999962



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian testing autoremoval watch@21:1/5 to All on Fri Jul 21 07:10:01 2023
    emacs-wgrep 3.0.0-1 is marked for autoremoval from testing on 2023-07-30

    It (build-)depends on packages with these RC bugs:
    999962: silversearcher-ag: depends on obsolete pcre3 library
    https://bugs.debian.org/999962



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian testing autoremoval watch@21:1/5 to All on Thu Aug 10 07:00:01 2023
    emacs-wgrep 3.0.0-1 is marked for autoremoval from testing on 2023-09-01

    It (build-)depends on packages with these RC bugs:
    999962: silversearcher-ag: depends on obsolete pcre3 library
    https://bugs.debian.org/999962



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian testing autoremoval watch@21:1/5 to All on Wed Aug 30 07:00:01 2023
    emacs-wgrep 3.0.0-1 is marked for autoremoval from testing on 2023-09-01

    It (build-)depends on packages with these RC bugs:
    999962: silversearcher-ag: depends on obsolete pcre3 library
    https://bugs.debian.org/999962



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian testing autoremoval watch@21:1/5 to All on Fri Oct 6 07:00:02 2023
    emacs-wgrep 3.0.0-1 is marked for autoremoval from testing on 2023-11-09

    It (build-)depends on packages with these RC bugs:
    1052937: f-el: FTBFS: make: *** [debian/rules:4: build] Error 25
    https://bugs.debian.org/1052937



    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian testing autoremoval watch@21:1/5 to All on Thu Dec 14 06:00:01 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian testing autoremoval watch@21:1/5 to All on Thu Jan 4 06:00:01 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Sowden@21:1/5 to Xiyue Deng on Sat Jan 6 21:40:01 2024
    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. :)

    J.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEbB20U2PvQDe9VtUXKYasCr3xBA0FAmWZrdYACgkQKYasCr3x BA1fcw/+LsqntXS47UGYCSzjVMQHLxblYf638Oxbcbp+1vqD8B7uq9g8/4Z2Zawo s7T6JGBZwTCJ03YZtEgg7a1tO/vY1gjqicLGo1z9d1qo+1IyW2Rm5+ShVP4zWK+/ XWvpW3WwxYJYpemL6mF9bIliTU1Tx5MlZxXlB9tb4Z/m9Lrze8epEWAhdpPYBMsv KInDlHM7Dft/7ZNQf+ItU8qMtKzbW53Xu4Hq60BC6nDRnb7UIzum6p0vUwgQKN/P bGNgGuU+e06h9nYtiQl1fNmg7hDQjo1PmRw29sZpENeBjaycr3VJDOUvk+au69jd MwL9cLcqP+sADHGmirkyTCL3zr7lV2pnt1HcSvMQDYrWVezUK8dX0xFf6C7Iwi/U NLw+YuYGIuCYmd9w/6Hhcv0CzeLOfd9LdoO3EKKVLtgdne8dY9kC8Dd/478fzmMJ F58Pzxu3jzAhr9XhSdH7gAv8ZTbaAZH0L5TwuyYyE7BsR2Q+zTftJQhgGT7ZCxki H0xFR+elrZUQpvg2Miq2ESXwcm6RcvjElBPiDcJ36NVznQy7Vmz9cRK6tF13eKpN LJ+1PaqaGdzP5bz0ZoQVntddn6U4gsgNs54gAYGOW5jd+7HFwDeY01Dp7FnI59C+ oviWy/4i6Bg7s+Nt7AKSqIQRoXwWJUqRe2UnzvfdGXKGqfhgszg=
    =VovY
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Sowden@21:1/5 to Xiyue Deng on Sun Jan 7 16:30:01 2024
    On 2024-01-06, at 18:16:31 -0800, Xiyue Deng wrote:
    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.

    Agreed. I was merely observing that the problem seemed directly related
    to the presence of the BOM -- removing it caused the tests to pass.

    Can you show me a bit more of your system and package info (with dependencies)?

    The tests were failing when I ran either:

    schroot -c sid -- fakeroot debian/rules clean binary

    which runs in an up-to-date Unstable schroot LVM snapshot chroot, or:

    gbp buildpackage --git-pbuilder

    which runs in an up-to-date Unstable cowbuilder chroot. When I tried an Unstable sbuild chroot that I have on the same host, the tests passed.
    They had also passed when I ran the tests in the host system, which is
    running Testing. I created a fresh Unstable cowbuilder chroot, but
    using that didn't help. 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`.

    Compare:

    $ schroot -c sid -- env LANG=C.UTF-8 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-07 14:07:46+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...
    Successfully finished. (1 changed)
    Buffer has been saved.
    passed 1/1 wgrep-bom-with-unibyte (0.911896 sec)

    Ran 1 tests, 1 results as expected, 0 unexpected (2024-01-07 14:07:46+0000, 0.912041 sec)

    and:

    $ schroot -c sid -- env LANG=C 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-07 14:10:21+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:
    [...]
    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.943495 sec) at wgrep-test.el:77

    Ran 1 tests, 0 results as expected, 1 unexpected (2024-01-07 14:10:22+0000, 1.124888 sec)

    1 unexpected results:
    FAILED wgrep-bom-with-unibyte

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

    J.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEbB20U2PvQDe9VtUXKYasCr3xBA0FAmWawegACgkQKYasCr3x BA0XWw//T3Q7KVYeEE2PaHtU2Fc7ZsY57Sn3GiF0vfpAiniDGk4jjivfvnfjSQq/ 5aTZxRBTz7mbQSzNmKFmXoai2pUCvvJGIqMoBTEW+ugEjkPEhkg7TK7Tes7yRTiZ t9/wXI3W1C5QzA3vAe6vuqEP+7z3PqIC3d14f79sxsU+w5a1eE31TYAdpmFj2mQ0 4O4tylGzDQwqMrgJgZihFb73OIk7ToBaGSl+nUQFnuXmPXAr9N2mlrgdC3S4FWEL ITnjDrUODaVRwGAI6Ogob5NaKcEbqDH+Fxhs0fAkDCfL1lyFImCNNd88uayp2ytF /eD/bvlfj6OWjQVt/iArsguQ0IQmGrtNTer8fLbtcQVgx9hbpazkXJhz3uIlD7Ja XtWJnDsKDWaY40qcbAO3msgTWP2te6zRGJaNji/4S4pCHKgusRSuhl8b/I2y0fLp IT7/sewMVlH27vRz9UuQxCGCZxPSGxjA//EBij+MyhGs1wBhFL917JCpdRsrdD/O CKPFapLnJzLH3E9mUR6DD15lEqmC9U7x/quH9yfQCkaTcY5oxKQTKG4s/bm1jmuT +dWeOjmJ+cfZy6i0yHGNTXTOhJjpSRl1g2BR5WyAdukuvt1anhuVhB7s+b7ZC4XJ 4lBkV8ESLH8NkCS1x3USHbPUed4KYTXJ5kOF/xXCje91mlp732E=
    =xnRB
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicholas D Steeves@21:1/5 to Xiyue Deng on Wed Jan 17 06:50:01 2024
    Xiyue Deng <manphiz@gmail.com> writes:

    Jeremy Sowden <jeremy@azazel.net> writes:

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

    [snip]

    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.

    Thanks,
    Nicholas

    -----BEGIN PGP SIGNATURE-----

    iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmWnaNAQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYY+qD/9pFW8NjXec78juFJD0zcns+tSUHc9i4VZU IWShsTRCsbsL+eaCueC3YYfrm3nH11i6AevCJtHuu4DET/jCK6K9Bns+aRuUoOEv MTg4wrQFL2jSgJvh3EjS5rnLgkOlK6mnsPzZjLOW+3mXUJM1fyq1hIPYXhXGsf7T F0K+crDczwoh9vKIM8o7Ma81sVO31PnTPQLXRKMMXcMpjRjEG4XveP9bGjuqx6Ep /qZdy0Bt6q7kcoVMszgHUDc73Sxm8RYhdEPHsWgaAkCeCLpHk6uawcS1QYVWKvOC d7940QVlnIG1FI7wzrEu+F0LPl8vvyYBEDKhl2AjlzNmUp3+TFbfd6FLcgsmqzkb fbp8vGavhRBKFEQMRFufCUrAaDB1lA4qFK2f3sjGFdcgYuj074lWBWDLcZeB6s6+ Ipi4TXrDuHnKP6RnFAOFNwQ64a+ploqkq2RHOyjcvtwMe5Vilh5DQyKAvvRBH+uf errSQDWdBGA4YpE/DyfsDmRLsX2KDCONcTkdX0ryybWYkzJ4faAYStsPuwbepdUD dHubg3CWe48p7jNkdCW3NUGpOYBU27g5GTzImUxVN+/+jmxivnGwLKgJDxs8tTY0 qqYfD38K2oPZjrPGEkH1A/Q0F/hecr267xCegBgWSBFp96jvgYcwdwd1P6b8a2NQ
    IJ3q3Wuinw==
    =zcBZ
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Sowden@21:1/5 to Nicholas D Steeves on Wed Jan 17 21:20:01 2024
    On 2024-01-16, at 22:42:40 -0700, Nicholas D Steeves wrote:
    Xiyue Deng <manphiz@gmail.com> writes:
    Jeremy Sowden <jeremy@azazel.net> writes:
    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`.

    [snip]

    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.

    Agreed. Thanks for the pointers. I had intended to file a separate
    bug-report to keep track of the problem and continue looking into it,
    but got distracted by a couple of things. I'll get the bug-report done
    later this week.

    As the package maintainer, I'm willing to sponsor at commit:fc1fac7 or equivalent.

    J.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEbB20U2PvQDe9VtUXKYasCr3xBA0FAmWoNQsACgkQKYasCr3x BA2VWhAAxFDVG7E2LdLPL61xhupE0T8cVROhdJl3dPzRSqQ0BCYyZEY+mulgqbMk HbYQpFMkydKJWs9RYeEmNNqKlx3SFovxk0gU4GSzEvOkctLttF4lurqfz456HkZd 6BQHDnVE4z3pYKVkAwGc41czFJtOGZtraT7wOx9R6cLvlswiPxu0fxyWbTlPOc0l njXyJCi3Fj4acMm2SpBaMdhaurWTWFqMdPbGbitq/cWkKPBZvNCuIK90KG/U1ooi WeYZniT+nBtmxqCX6lTiqt6U8X7DVTyOYMLGLjyXGnOf+kidxZ3IRd7QXPXzreLH 4OJj9n36jqoQSwuGl5NPi9+9Z4iYmNpmvG5JL/SxRZfrSigAF43ffCANvsviqTPC C+W9Po7+KXEUan5AChGcqsCi/qBjC1r+c9LwEC6E1/RZOL5JPnCPuKFgY3gSPYgP ofsI8mm3grAxU71X1f55IuINBc0HPh12YCXyfCEoMFfmP/+RoaNTZ+cSPo1eJtsQ 0yUkiPogXL7aJViXwyspIm3PzbOMq2nv+467Rpjl9l2t+F2VQbndwkf4lbbWTDoS wDaGHRMkTHQi30eYH3KsSf9BveIcTIO7Cqr+a2r94fjoyFT586/SKDN+Az8ylKj/ yiAdZLR+VwGUo0QZo9LncH0YykBoxSqzdesTWETw1cf+5d8yzGI=
    =b8lH
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicholas D Steeves@21:1/5 to Xiyue Deng on Fri Jan 19 06:30:01 2024
    Xiyue Deng <manphiz@gmail.com> writes:

    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.

    Yup, I've been aware of the issue for a while, and have been deferring
    its resolution for a while because I haven't seriously looked into
    encodings, and because the objective isn't to make the tests
    superficially pass.

    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.

    I found time to review your changes. Once again, the changelog should unambiguously document changes to the package without requiring git
    history to interpret any changelog entry.

    See changelog and git log for further info.

    The UTF-8 issue appears to be present in autopkgtests, but I can't
    remember if this is an old or a new issue. IIRC there was something on debian-devel about how they're going to become more important for trixie
    or trixie+1. I think it said the bounty would be dropped and some sort
    of penalty or block would be introduced. Test this with

    $ autopkgtest -- schroot sid-amd64-sbuild

    Do these pass on your systems?

    And here's an interesting discussion that is, at worst, tangentially
    related to the problem:
    https://stackoverflow.com/questions/2223882/whats-the-difference-between-utf-8-and-utf-8-with-bom


    Cheers,
    Nicholas

    -----BEGIN PGP SIGNATURE-----

    iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmWqCGoQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYTWXEADa0R9aAy9FUenonMRqvOUIW7l/0pA+HOXv WquLFfTZyXSaU3nv/vUTj75dt+HUqVMFqkyPVuu+8HNNqVc44Dc8FxL5vPevSdUe Fa1sOjtsBZClDvUcC8eO6a8ChxqPQ46cLwvDPoPXMalpxg586kCJuV4VEqjRLuay wLOe/xQ/HyjA29MVsjqtgvvTAVXTzgMjbUK88Mppcslzd45MGnjSH6yspVefgM9v F6LIDUA9yH8Ty/QbRLUgRb8/FIfdxfmNz1gCKIPQKzQcJ3Ehc/4hBKp0/Op8cR4w N5pgHsoYEPo071ve3z6lyKfkTTZySQ28xvwfVrife5EHAkP4bkZAlqwQnFIMGFP3 SpaowpjHJ55KXteM46kkV/Cq4Vjk+LCxcoUcQGuwcWZTCYYMAh+rYbVV3aGVI8N2 rGrDB3WhnuST+o7FfdME2NydWUIuufRvdfWsdSeQ6RLWGg5Rqr3/LdgNgqPxbcwe mGvezb4nx12Y5VCPt46OQwT+GUrqZbhSQSkTKq+HFVuyTafLX9Ge4Yrt2+j2nDXv UD7++NKTrxrG7myAaxWwhWzpEkp3YprmryD3RXZYiO2xUIrwVUcsnwWHiQqmEbH7 sB4jSlZFftXUfN6oz3FRjFuND1QakNK20Krp9fa+plplAOT8QWlTuaa9GnCiBe6m
    fZS1sKJLgQ==
    =zLD1
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)